From nobody Sun Nov 9 12:19:58 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 02:49:37 +1100 Lines: 27 Approved: news@gmane.org Message-ID: <200311030249.37020.russell@coker.com.au> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067788530 10779 80.91.224.253 (2 Nov 2003 15:55:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2003 15:55:30 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Sun Nov 02 16:55:28 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGKZc-0002nt-00 for ; Sun, 02 Nov 2003 16:55:28 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C53FA1F455; Sun, 2 Nov 2003 09:55:01 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id AA06A1F454 for ; Sun, 2 Nov 2003 09:54:54 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 6F446925E8 for ; Mon, 3 Nov 2003 02:54:52 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id 84BD27F005 for ; Mon, 3 Nov 2003 02:49:37 +1100 (EST) Original-To: Debian Devel User-Agent: KMail/1.5.4 Content-Disposition: inline Resent-Message-ID: <2vC9y.A.q2H.VjSp_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154901 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Sun, 2 Nov 2003 09:55:01 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44284 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44284 http://people.redhat.com/mingo/exec-shield/ http://kerneltrap.org/node/view/913 It seems that exec-shield does 99% of what PaX does (PaX is the most desirable feature in GRSec). Exec-shield also has support for 2.6 and looks like it will be a standard feature in Red Hat. I have just built a kernel from the Debian kernel-source-2.4.22 package with exec-shield, the patch applied cleanly and it appears to work well. Maybe we should solve the debate about grsec and standard kernels by adding exec-shield to the standard Debian kernel source? Then people who use a kernel.org kernel can apply the grsec patch (which will not apply to a Debian kernel source tree), and people who use the Debian kernel source will get exec-shield by default? If adding exec-shield to the Debian kernel is not considered a good idea then I'll create a kernel-patch package for exec-shield, which will still remove the need to make grsec work with the Debian kernel. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:01 2003 Path: main.gmane.org!not-for-mail From: Michael Ablassmeier Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Sun, 2 Nov 2003 20:14:32 +0100 Lines: 30 Approved: news@gmane.org Message-ID: <20031102191432.GA5640@mail.schiach.de> References: <200311030249.37020.russell@coker.com.au> Reply-To: abi@grinser.de NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Trace: sea.gmane.org 1067800384 830 80.91.224.253 (2 Nov 2003 19:13:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2003 19:13:04 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Sun Nov 02 20:13:02 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGNen-0002U6-00 for ; Sun, 02 Nov 2003 20:13:01 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 7FC151F60B; Sun, 2 Nov 2003 13:12:25 -0600 (CST) Old-Return-Path: Original-Received: from schiach.de (enz.schiach.de [213.239.192.71]) by murphy.debian.org (Postfix) with ESMTP id 03D891F565 for ; Sun, 2 Nov 2003 13:12:16 -0600 (CST) Original-Received: from radiohead (pD9EBF852.dip.t-dialin.net [217.235.248.82]) by schiach.de (Postfix) with ESMTP id E9CB62107E for ; Sun, 2 Nov 2003 20:11:39 +0100 (CET) Original-Received: by radiohead (Postfix, from userid 1000) id 375FD7DF9; Sun, 2 Nov 2003 20:14:32 +0100 (CET) Original-To: Debian Devel Mail-Followup-To: Michael Ablassmeier , Debian Devel Content-Disposition: inline In-Reply-To: <200311030249.37020.russell@coker.com.au> X-Accept-Language: de en User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154906 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Sun, 2 Nov 2003 13:12:25 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44289 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44289 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Nov 03, 2003 at 02:49:37AM +1100, Russell Coker wrote: > It seems that exec-shield does 99% of what PaX does (PaX is the most desirable > feature in GRSec). Exec-shield also has support for 2.6 and looks like it > will be a standard feature in Red Hat. I don't know exec-shield that good, but i think it may be better to not only test it one or 2 days. So, let's look how it works for RedHat and provide an kernel-patch package (my suggestion). > If adding exec-shield to the Debian kernel is not considered a good idea then > I'll create a kernel-patch package for exec-shield, which will still remove > the need to make grsec work with the Debian kernel. Even if it has some features which are nice, grsec provides a few more. It would be nice to have a working grsec Patch in Debian. bye, - michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pVeYEFV7g4B8rCURAvaUAKCoB0TcKQbuWZzq6U1uZnllsYODpgCfePaE T8/Ge9Z8FL9olSRZCXcAMxg= =Aznc -----END PGP SIGNATURE----- From nobody Sun Nov 9 12:20:01 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 07:45:38 +1100 Lines: 41 Approved: news@gmane.org Message-ID: <200311030745.38670.russell@coker.com.au> References: <200311030249.37020.russell@coker.com.au> <20031102191432.GA5640@mail.schiach.de> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067806306 10837 80.91.224.253 (2 Nov 2003 20:51:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2003 20:51:46 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Sun Nov 02 21:51:44 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGPCK-0006HP-00 for ; Sun, 02 Nov 2003 21:51:44 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E1E891FB03; Sun, 2 Nov 2003 14:51:03 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id 474B51FA81 for ; Sun, 2 Nov 2003 14:50:54 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 10250925E8; Mon, 3 Nov 2003 07:50:53 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id 2EE5D7F005; Mon, 3 Nov 2003 07:45:39 +1100 (EST) Original-To: abi@grinser.de, Debian Devel User-Agent: KMail/1.5.4 In-Reply-To: <20031102191432.GA5640@mail.schiach.de> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154911 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Sun, 2 Nov 2003 14:51:03 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44294 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44294 On Mon, 3 Nov 2003 06:14, Michael Ablassmeier wrote: > On Mon, Nov 03, 2003 at 02:49:37AM +1100, Russell Coker wrote: > > It seems that exec-shield does 99% of what PaX does (PaX is the most > > desirable feature in GRSec). Exec-shield also has support for 2.6 and > > looks like it will be a standard feature in Red Hat. > > I don't know exec-shield that good, but i think it may be better to not > only test it one or 2 days. So, let's look how it works for RedHat and > provide an kernel-patch package (my suggestion). Exec-shield is apparently in Fedora already, and has been tested extensively inside Red Hat. The plan is to get Linus to accept it as a feature for 2.6, but to do this we need to get it tested more. It is being tested in Fedora, I think that we should do the same for Debian. Getting this patch deployed on large numbers of Debian machines is what is necessary to get it accepted by Linus. I will make a kernel-patch package. > > If adding exec-shield to the Debian kernel is not considered a good idea > > then I'll create a kernel-patch package for exec-shield, which will still > > remove the need to make grsec work with the Debian kernel. > > Even if it has some features which are nice, grsec provides a few more. > It would be nice to have a working grsec Patch in Debian. We have recently discussed grsec, and it seems that we will not get grsec as either a default part of the Debian kernel, or as a patch that can be applied to a Debian kernel. PS I am employed by Red Hat, but this has no direct connection to my work. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:02 2003 Path: main.gmane.org!not-for-mail From: Michael Ablassmeier Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Sun, 2 Nov 2003 22:05:09 +0100 Lines: 32 Approved: news@gmane.org Message-ID: <20031102210509.GA6357@mail.schiach.de> References: <200311030249.37020.russell@coker.com.au> <20031102191432.GA5640@mail.schiach.de> <200311030745.38670.russell@coker.com.au> Reply-To: abi@grinser.de NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Trace: sea.gmane.org 1067806995 12216 80.91.224.253 (2 Nov 2003 21:03:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2003 21:03:15 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Sun Nov 02 22:03:13 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGPNR-0006sq-00 for ; Sun, 02 Nov 2003 22:03:13 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id D8C351FB13; Sun, 2 Nov 2003 15:02:56 -0600 (CST) Old-Return-Path: Original-Received: from schiach.de (enz.schiach.de [213.239.192.71]) by murphy.debian.org (Postfix) with ESMTP id 7AD1E1F3E1 for ; Sun, 2 Nov 2003 15:02:52 -0600 (CST) Original-Received: from radiohead (pD9EBF852.dip.t-dialin.net [217.235.248.82]) by schiach.de (Postfix) with ESMTP id 6E3D32109B for ; Sun, 2 Nov 2003 22:02:16 +0100 (CET) Original-Received: by radiohead (Postfix, from userid 1000) id 4EF727DF9; Sun, 2 Nov 2003 22:05:09 +0100 (CET) Original-To: Debian Devel Mail-Followup-To: Michael Ablassmeier , Debian Devel Content-Disposition: inline In-Reply-To: <200311030745.38670.russell@coker.com.au> X-Accept-Language: de en User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154912 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Sun, 2 Nov 2003 15:02:56 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44295 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44295 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi Russell, On Mon, Nov 03, 2003 at 07:45:38AM +1100, Russell Coker wrote: > The plan is to get Linus to accept it as a feature for 2.6, but to do this we > need to get it tested more. It is being tested in Fedora, I think that we > should do the same for Debian. Getting this patch deployed on large numbers > of Debian machines is what is necessary to get it accepted by Linus. Okey. > We have recently discussed grsec, and it seems that we will not get grsec as > either a default part of the Debian kernel, or as a patch that can be applied > to a Debian kernel. Jap, i hope to see the GRSecurity options provided by "make menuconfig" at the "Security Options" section in newer Kernels (like SELinux). Are there any plans? bye, - michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pXGFEFV7g4B8rCURAgUzAKCNbUrx2phPRP3xBdv5FPL7XwakTwCfWaCw J8wJr0qDxH8yrUscoW/OH/A= =/bWe -----END PGP SIGNATURE----- From nobody Sun Nov 9 12:20:03 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 08:20:05 +1100 Lines: 19 Approved: news@gmane.org Message-ID: <200311030820.05380.russell@coker.com.au> References: <200311030249.37020.russell@coker.com.au> <200311030745.38670.russell@coker.com.au> <20031102210509.GA6357@mail.schiach.de> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067808394 14655 80.91.224.253 (2 Nov 2003 21:26:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2003 21:26:34 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Sun Nov 02 22:26:32 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGPjz-0007rZ-00 for ; Sun, 02 Nov 2003 22:26:32 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id ACF4A1FB91; Sun, 2 Nov 2003 15:25:53 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id 9FD051FB87 for ; Sun, 2 Nov 2003 15:25:37 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id B9FA1925E8; Mon, 3 Nov 2003 08:25:36 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id E01C67F005; Mon, 3 Nov 2003 08:20:05 +1100 (EST) Original-To: abi@grinser.de, Debian Devel User-Agent: KMail/1.5.4 In-Reply-To: <20031102210509.GA6357@mail.schiach.de> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154915 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Sun, 2 Nov 2003 15:25:53 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44298 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44298 On Mon, 3 Nov 2003 08:05, Michael Ablassmeier wrote: > > We have recently discussed grsec, and it seems that we will not get grsec > > as either a default part of the Debian kernel, or as a patch that can be > > applied to a Debian kernel. > > Jap, i hope to see the GRSecurity options provided by "make menuconfig" > at the "Security Options" section in newer Kernels (like SELinux). Are > there any plans? LSM is in the kernel.org kernels in 2.6. So if GRSec is ported to LSM then it should be possible to get it included in a standard kernel.org kernel. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:03 2003 Path: main.gmane.org!not-for-mail From: Michael Ablassmeier Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 10:25:31 +0100 Lines: 17 Approved: news@gmane.org Message-ID: <20031103092531.GA14752@jail.schiach.de> References: <200311030249.37020.russell@coker.com.au> <200311030745.38670.russell@coker.com.au> <20031102210509.GA6357@mail.schiach.de> <200311030820.05380.russell@coker.com.au> Reply-To: abi@grinser.de NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067851726 1538 80.91.224.253 (3 Nov 2003 09:28:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 09:28:46 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 10:28:44 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGb0u-0006mG-00 for ; Mon, 03 Nov 2003 10:28:44 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id DC65C1F47E; Mon, 3 Nov 2003 03:26:17 -0600 (CST) Old-Return-Path: Original-Received: from schiach.de (enz.schiach.de [213.239.192.71]) by murphy.debian.org (Postfix) with ESMTP id DB4761F3F0 for ; Mon, 3 Nov 2003 03:26:07 -0600 (CST) Original-Received: by schiach.de (Postfix, from userid 2002) id 79FBD210A6; Mon, 3 Nov 2003 10:25:31 +0100 (CET) Original-To: debian-devel@lists.debian.org Mail-Followup-To: Michael Ablassmeier , debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <200311030820.05380.russell@coker.com.au> User-Agent: Mutt/1.4.1i X-Accept-Language: de en Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154928 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 03:26:17 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44312 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44312 On Mon, Nov 03, 2003 at 08:20:05AM +1100, Russell Coker wrote: > LSM is in the kernel.org kernels in 2.6. So if GRSec is ported to LSM then it > should be possible to get it included in a standard kernel.org kernel. hm, http://www.grsecurity.net/lsm.php: [...] The amount of work required to port to LSM is very large, and could be spent on solving real problems rather than porting pre-existing code to a framework that is likely to change (as they realize it is unsuitable for most purposes) [...] bye, - michael From nobody Sun Nov 9 12:20:04 2003 Path: main.gmane.org!not-for-mail From: Gustavo Franco Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 03 Nov 2003 00:47:38 -0200 Lines: 21 Approved: news@gmane.org Message-ID: <3FA5C1CA.1040105@legolas.alternex.com.br> References: <200311030249.37020.russell@coker.com.au> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067827664 31485 80.91.224.253 (3 Nov 2003 02:47:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 02:47:44 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 03:47:41 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGUkm-0002jL-00 for ; Mon, 03 Nov 2003 03:47:41 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 852471F8A5; Sun, 2 Nov 2003 20:47:26 -0600 (CST) Old-Return-Path: Original-Received: from itaqui.terra.com.br (itaqui.terra.com.br [200.176.3.19]) by murphy.debian.org (Postfix) with ESMTP id 472A01F86D for ; Sun, 2 Nov 2003 20:47:22 -0600 (CST) Original-Received: from barcelona.terra.com.br (barcelona.terra.com.br [200.176.3.41]) by itaqui.terra.com.br (Postfix) with ESMTP id 261D9810159 for ; Mon, 3 Nov 2003 00:47:21 -0200 (BRST) Original-Received: from legolas.alternex.com.br (RJ178026.user.veloxzone.com.br [200.149.178.26]) (authenticated user grfranco) by barcelona.terra.com.br (Postfix) with ESMTP id C1E8F2D69A4 for ; Mon, 3 Nov 2003 00:47:20 -0200 (BRST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031017 Thunderbird/0.3 X-Accept-Language: en-us, en Original-To: debian-devel@lists.debian.org In-Reply-To: <200311030249.37020.russell@coker.com.au> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154920 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Sun, 2 Nov 2003 20:47:26 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44304 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44304 Russell Coker wrote: >http://people.redhat.com/mingo/exec-shield/ >http://kerneltrap.org/node/view/913 > >It seems that exec-shield does 99% of what PaX does (PaX is the most desirable >feature in GRSec). Exec-shield also has support for 2.6 and looks like it >will be a standard feature in Red Hat. > > > I believe that exec-shield doesn't 99% of what PaX does, do some tests with paxtest[1], but i like the idea of merge the patch with "debian kernel" in the future. [1] = http://pageexec.virtualave.net/paxtest-0.9.4.tar.gz Bye, Gustavo Franco -- From nobody Sun Nov 9 12:20:04 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 14:30:55 +1100 Lines: 27 Approved: news@gmane.org Message-ID: <200311031430.55497.russell@coker.com.au> References: <200311030249.37020.russell@coker.com.au> <3FA5C1CA.1040105@legolas.alternex.com.br> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067830599 2781 80.91.224.253 (3 Nov 2003 03:36:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 03:36:39 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 04:36:37 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGVW9-0004BN-00 for ; Mon, 03 Nov 2003 04:36:37 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id DD6591F8FA; Sun, 2 Nov 2003 21:36:13 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id 8DF651F5E6 for ; Sun, 2 Nov 2003 21:36:09 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 488CA925E8; Mon, 3 Nov 2003 14:36:08 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id 12F247F019; Mon, 3 Nov 2003 14:30:56 +1100 (EST) Original-To: Gustavo Franco , debian-devel@lists.debian.org User-Agent: KMail/1.5.4 In-Reply-To: <3FA5C1CA.1040105@legolas.alternex.com.br> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154922 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Sun, 2 Nov 2003 21:36:13 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44306 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44306 On Mon, 3 Nov 2003 13:47, Gustavo Franco wrote: > Russell Coker wrote: > >http://people.redhat.com/mingo/exec-shield/ > >http://kerneltrap.org/node/view/913 > > > >It seems that exec-shield does 99% of what PaX does (PaX is the most > > desirable feature in GRSec). Exec-shield also has support for 2.6 and > > looks like it will be a standard feature in Red Hat. > > I believe that exec-shield doesn't 99% of what PaX does, do some tests > with paxtest[1], but > i like the idea of merge the patch with "debian kernel" in the future. I quickly checked out paxtest, there are a number of issues listed as "Vulnerable", but I believe that some of those are necessary for full functionality of programs such as X servers. The aim of exec-shield is to have no need of a "chpax" type program. Also exec-shield will do even better when we have a tool chain supporting PIE, this is already in Fedora, and will be in Debian by gcc 3.4 if not before. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:04 2003 Path: main.gmane.org!not-for-mail From: spender@grsecurity.net Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 07:42:27 -0500 Lines: 120 Approved: news@gmane.org Message-ID: <20031103124227.GA19895@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" X-Trace: sea.gmane.org 1067865607 31658 80.91.224.253 (3 Nov 2003 13:20:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 13:20:07 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 14:20:05 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGecm-00013c-00 for ; Mon, 03 Nov 2003 14:20:04 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 611E91F532; Mon, 3 Nov 2003 07:19:21 -0600 (CST) Old-Return-Path: Original-Received: from grsecurity.net (grsecurity.net [63.100.47.84]) by murphy.debian.org (Postfix) with ESMTP id 69B411F4AE for ; Mon, 3 Nov 2003 07:00:25 -0600 (CST) Original-Received: by grsecurity.net (Postfix, from userid 1000) id 7398C5B686; Mon, 3 Nov 2003 07:42:27 -0500 (EST) Original-To: russell@coker.com.au Content-Disposition: inline User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154930 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 07:19:21 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44314 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44314 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3DUTF-8&safe=3D= off&selm=3DNsO7.6tw.3%40gated-at.bofh.it > It seems that exec-shield does 99% of what PaX does (PaX is the most desi= rable=20 > feature in GRSec). Exec-shield also has support for 2.6 and looks like i= t=20 > will be a standard feature in Red Hat. This comment is false, unfounded, and a slap in the face of both me and=20 the PaX team. Apparently you've not read my presentation slides here: http://grsecurity.net/PaX-presentation_files/frame.htm comparing PaX to W^X and Exec-shield. Had you read it, you would=20 understand that Exec-shield doesn't even do 50% of what PaX does. =20 Exec-shield doesn't support the architectures PaX does. Exec-shield=20 doesn't do kernel stack randomization or non-executable kernel pages. =20 It can't guarantee that when a task is fully loaded, that its mappings=20 are W^X, even if it didn't request such mappings. It has less=20 randomization than PaX in all areas. HOW do you figure that exec-shield=20 does 99% of what PaX does? Where's your research? You have clearly=20 done no research whatsoever, so please spare the debian users of your=20 ignorant tripe. > Maybe we should solve the debate about grsec and standard kernels by addi= ng=20 > exec-shield to the standard Debian kernel source? Go ahead and do it. I could frankly care less if your users get owned. =20 Give them a false sense of security by telling them that Exec-shield=20 is a substitute for grsecurity and PaX. http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3DUTF-8&safe=3D= off&selm=3DNxus.4xi.5%40gated-at.bofh.it > Exec-shield is apparently in Fedora already, and has been tested extensiv= ely=20 > inside Red Hat. Apparently not too extensively. Maybe you forgot a few weeks ago an=20 exploitable bug was fixed in Exec-shield. It had been in the code since=20 it was first written. Was this found by the "extensive testing" by=20 RedHat? No, they were just lucky that someone ran paxtest on it, and=20 found the 4k of writable and executable bss/data. There's another=20 exploitable bug in Exec-shield that I've known of for months. Maybe=20 you'll find it after you put it into Debian. Maybe not. This is what=20 happens when you make rush judgements and choose to use something based=20 solely on who developed it. Where's the attack model? Where's the=20 explanation of why the randomization is done the way it is? They don't=20 exist. How do you expect to make any kind of informed decision if=20 you have no idea what you're talking about? Why should anyone listen to=20 what you have to say when you've done no research? "It works for=20 RedHat" and "I've been using it for 2 days" is not research. > We have recently discussed grsec, and it seems that we will not get grsec= as=20 > either a default part of the Debian kernel, or as a patch that can be app= lied=20 > to a Debian kernel. I've read the post regarding grsecurity and Debian, and I must say=20 that I've never seen a bigger bunch of lazy whiners in my life. Maybe if y= ou=20 actually put a kernel hacker in charge of these patches, you'd realize=20 you have been whining for months for no reason. Did you ever think that=20 putting someone in charge who can code in C might help? Or were you=20 planning on relying on diff fuzz for the next couple years? http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3DUTF-8&safe=3D= off&selm=3DNDJr.4vv.1%40gated-at.bofh.it > I quickly checked out paxtest, there are a number of issues listed as=20 > "Vulnerable", but I believe that some of those are necessary for full=20 > functionality of programs such as X servers. You believe incorrectly. You work at RedHat. You must know they've=20 modified X so that it works properly with Exec-shield. You must know=20 that PaX doesn't break X, but rather that the bug in X causing the=20 problem is only visible when PaX is used. Stop spreading these lies,=20 and blowing off the ineffectiveness of Exec-shield. XFree86-4.3.0-elfloader-linux-non-exec-stack-v2.patch XFree86-4.3.0-redhat-libGL-exec-shield-fixes-v2.patch Since this is probably the fourth time I've had to correct you on making=20 false, unresearched statements publicly, I'm cc'ing this one to the=20 list, to show your users who's making their security decisions for them. I've tried to do it in a more professional manner before by not=20 embarrassing you in front of your peers, however you don't seem to want=20 to stop this habit, which at this point I believe verges on=20 maliciousness. I'm going to point out your mails to the PaX team, and they will comment=20 on them as well if they see fit. Feel free to reply after you have done the research I've done on the=20 subject and can make a factual counter-argument. -Brad --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/pk0wmHm2SUJF1GoRAgPQAJ4jHtbQJFr77fqfqN+zWEKLarm1/QCfXSWN HTNbOfCPnMaohc21NXSuVJY= =j9pC -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From nobody Sun Nov 9 12:20:05 2003 Path: main.gmane.org!not-for-mail From: Theodore Ts'o Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 09:41:03 -0500 Lines: 25 Sender: Theodore Ts'o Approved: news@gmane.org Message-ID: <20031103144103.GA9755@thunk.org> References: <20031103124227.GA19895@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067870578 11695 80.91.224.253 (3 Nov 2003 14:42:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 14:42:58 +0000 (UTC) Cc: russell@coker.com.au, debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 15:42:53 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGfuv-00063D-00 for ; Mon, 03 Nov 2003 15:42:53 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id D525A1F5AD; Mon, 3 Nov 2003 08:41:38 -0600 (CST) Old-Return-Path: Original-Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by murphy.debian.org (Postfix) with ESMTP id 50DC01F597 for ; Mon, 3 Nov 2003 08:41:26 -0600 (CST) Original-Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1AGftD-0006Ev-00; Mon, 03 Nov 2003 09:41:07 -0500 Original-Received: from tytso by thunk.org with local (Exim 4.24) id 1AGftA-0004iX-OE; Mon, 03 Nov 2003 09:41:04 -0500 Original-To: spender@grsecurity.net Content-Disposition: inline In-Reply-To: <20031103124227.GA19895@grsecurity.net> User-Agent: Mutt/1.5.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154933 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 08:41:38 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44317 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44317 >From reading the techincal descriptions of PaX and Exec-shield, there does seem to be one, major advantage of Exec-shield over PaX, and that is that PaX takes the pathetically small, undersized space available to userspace applications on 32-bit architectures (i.e., only 3GB) and cuts it down into half (i.e, 1.5 GB). Given the fragmentation of how the userspace memory has to be used (for shared libraries, mmap'ed regious both for files and for large malloc allocations, stack, program text), etc, this is could be a major problem for some applications. Randomizing the shared libraries, as PaX does, for every single invocation, also comes with some tradeoffs. In particular this would mean that it is incompatible with prelink, which speeds up the loading of applications with large numbers of shared libraries. (Some systems/distro's run "prelink -afR" out of cron to re-randomize the layout every day, which seems to be a nice compromise.) Discalimer: I've only read the technical docs, and haven't had time to do a detailed examination of the sources, so if the descriptions are wrong or misleading, some details in this note might be incorrect. I apologize in advance if I've gotten any of the details wrong. - Ted From nobody Sun Nov 9 12:20:06 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Tue, 4 Nov 2003 03:20:19 +1100 Lines: 87 Approved: news@gmane.org Message-ID: <200311040320.19172.russell@coker.com.au> References: <20031103124227.GA19895@grsecurity.net> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067876830 28108 80.91.224.253 (3 Nov 2003 16:27:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 16:27:10 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 17:27:07 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGhXn-0005zq-00 for ; Mon, 03 Nov 2003 17:27:07 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 961731F7C4; Mon, 3 Nov 2003 10:25:45 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id 4FE3D1F799 for ; Mon, 3 Nov 2003 10:25:33 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id AFA4E92604; Tue, 4 Nov 2003 03:25:31 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id AEC007F019; Tue, 4 Nov 2003 03:20:19 +1100 (EST) Original-To: spender@grsecurity.net User-Agent: KMail/1.5.4 In-Reply-To: <20031103124227.GA19895@grsecurity.net> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154942 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 10:25:45 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44326 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44326 On Mon, 3 Nov 2003 23:42, spender@grsecurity.net wrote: > > Maybe we should solve the debate about grsec and standard kernels by > > adding exec-shield to the standard Debian kernel source? > > Go ahead and do it. I could frankly care less if your users get owned. > Give them a false sense of security by telling them that Exec-shield > is a substitute for grsecurity and PaX. The problem is that we don't have anyone who has the time and ability to merge PaX with the Debian kernel patches. The exec-shield patch applies with the Debian patches and with LSM. I am prepared to maintain it. Unless someone volunteers to maintain PaX support for Debian kernels then the best available option for Debian users will be exec-shield. > > We have recently discussed grsec, and it seems that we will not get grsec > > as either a default part of the Debian kernel, or as a patch that can be > > applied to a Debian kernel. > > I've read the post regarding grsecurity and Debian, and I must say > that I've never seen a bigger bunch of lazy whiners in my life. Maybe if > you actually put a kernel hacker in charge of these patches, you'd realize > you have been whining for months for no reason. Did you ever think that > putting someone in charge who can code in C might help? Or were you > planning on relying on diff fuzz for the next couple years? Debian is not a company, we can't "put someone in charge", we rely on volunteers. If you wish to volunteer to become a Debian developer and maintain such things then your contributions would be welcome. > > I quickly checked out paxtest, there are a number of issues listed as > > "Vulnerable", but I believe that some of those are necessary for full > > functionality of programs such as X servers. > > You believe incorrectly. You work at RedHat. You must know they've > modified X so that it works properly with Exec-shield. You must know Actually I didn't know about the details of X modifications. The X server does some unusual things and therefore does not get protected in a default configuration. We can get such changes into Debian, but I think that we need the kernel patch first. > Since this is probably the fourth time I've had to correct you on making > false, unresearched statements publicly, I'm cc'ing this one to the > list, to show your users who's making their security decisions for them. Actually I don't want to make security decisions for users. This is why I initially maintained the Debian patch package for grsec, I have promoted OpenWall, I packaged RSBAC (but had to dump it because I didn't have the resources to test it and no-one else was interested), and now I'm working on SE Linux. I want the users to have as many choices as possible. But in the case of memory protection I think that we need to have the default kernel offer something. Surely you will agree that adding exec-shield is significantly better than the current situation. > I've tried to do it in a more professional manner before by not > embarrassing you in front of your peers, however you don't seem to want > to stop this habit, which at this point I believe verges on > maliciousness. The Debian social contract specifies that we will not hide problems. The project is based on free and open discussion. I have no problems with matters such as this being discussed publically. If someone believes that they can maintain a package better than an existing Debian developer then they are welcome to join in. If you volunteer to do PaX work for Debian then I am sure that you can make a good case for PaX in the default Debian kernel. If you choose not to do such work and no-one else who has appropriate skills volunteers then I guess that exec-shield will be likely to become default in Debian. This is nothing personal, it's a matter of practicality. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:06 2003 Path: main.gmane.org!not-for-mail From: cobaco Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Tue, 4 Nov 2003 11:29:28 +0100 Lines: 50 Approved: news@gmane.org Message-ID: <200311041129.28237.cobaco@linux.be> References: <20031103124227.GA19895@grsecurity.net> <200311040320.19172.russell@coker.com.au> Reply-To: cobaco@linux.be NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1068021365 19729 80.91.224.253 (5 Nov 2003 08:36:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 08:36:05 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 09:36:03 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHJ91-0007Zv-00 for ; Wed, 05 Nov 2003 09:36:03 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 621BB1F81A; Wed, 5 Nov 2003 02:35:40 -0600 (CST) Old-Return-Path: Original-Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by murphy.debian.org (Postfix) with ESMTP id 472CD1F501 for ; Wed, 5 Nov 2003 02:18:24 -0600 (CST) Original-Received: from 10.0.11.93 cobaco@smtp-send.myrealbox.com [62.133.193.10] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 3.44 $ on Novell NetWare via secured & encrypted transport (TLS); Wed, 05 Nov 2003 01:18:23 -0700 Original-To: debian-devel@lists.debian.org User-Agent: KMail/1.5.4 In-Reply-To: <200311040320.19172.russell@coker.com.au> Content-Description: clearsigned data Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155086 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 02:35:40 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44470 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44470 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2003-11-03 17:20, Russell Coker wrote: > On Mon, 3 Nov 2003 23:42, spender@grsecurity.net wrote: > > > Maybe we should solve the debate about grsec and standard kernels by > > > adding exec-shield to the standard Debian kernel source? > > > > Go ahead and do it. I could frankly care less if your users get owned. > > Give them a false sense of security by telling them that Exec-shield > > is a substitute for grsecurity and PaX. > > The problem is that we don't have anyone who has the time and ability to > merge PaX with the Debian kernel patches. > > The exec-shield patch applies with the Debian patches and with LSM. I am > prepared to maintain it. Unless someone volunteers to maintain PaX > support for Debian kernels then the best available option for Debian users > will be exec-shield. hm, the adamantix guys use PaX, maybe they ought to be pinged about this? > Actually I don't want to make security decisions for users. This is why I > initially maintained the Debian patch package for grsec, I have promoted > OpenWall, I packaged RSBAC (but had to dump it because I didn't have the > resources to test it and no-one else was interested), and now I'm working > on SE Linux. > > I want the users to have as many choices as possible. adamantix also uses RSBAC if I'm not mistaken =2D --=20 Cheers, cobaco /"\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request =A0X =A0 i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards =A0 =A0 http://www.fsf.org/philosophy/no-word-attachments.html =A0 =A0 http://www.goldmark.org/netrants/no-word/attach.html =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/p3+I5ihPJ4ZiSrsRAsCaAJ4004STNUj9aYpTNfek8VzbD7YLFgCfa+85 toqP6RWRqp2GO9KYpURkJiQ=3D =3Dglf9 =2D----END PGP SIGNATURE----- From nobody Sun Nov 9 12:20:07 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Thu, 6 Nov 2003 02:43:30 +1100 Lines: 27 Approved: news@gmane.org Message-ID: <200311060243.30619.russell@coker.com.au> References: <20031103124227.GA19895@grsecurity.net> <200311040320.19172.russell@coker.com.au> <200311041129.28237.cobaco@linux.be> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1068047637 29259 80.91.224.253 (5 Nov 2003 15:53:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 15:53:57 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 16:53:55 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHPyl-00083G-00 for ; Wed, 05 Nov 2003 16:53:55 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 237D81FAD5; Wed, 5 Nov 2003 09:48:50 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id 784EE1F68D for ; Wed, 5 Nov 2003 09:48:40 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 3719F9260B; Thu, 6 Nov 2003 02:48:39 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id 2CAAD7F03B; Thu, 6 Nov 2003 02:43:31 +1100 (EST) Original-To: cobaco@linux.be, debian-devel@lists.debian.org User-Agent: KMail/1.5.4 In-Reply-To: <200311041129.28237.cobaco@linux.be> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155117 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 09:48:50 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44501 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44501 On Tue, 4 Nov 2003 21:29, cobaco wrote: > > The exec-shield patch applies with the Debian patches and with LSM. I am > > prepared to maintain it. Unless someone volunteers to maintain PaX > > support for Debian kernels then the best available option for Debian > > users will be exec-shield. > > hm, the adamantix guys use PaX, maybe they ought to be pinged about this? Peter Busser is THE Adamantix guy. I have suggested to him that he maintain such packages in Debian, but he does not seem interested. > > I want the users to have as many choices as possible. > > adamantix also uses RSBAC if I'm not mistaken Yes. I made some RSBAC kernel-patch packages for Debian once, but never uploaded them because no-one was interested in helping to test them. When no-one wants to test a package you have to assume that there is not much interest in using it either... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:07 2003 Path: main.gmane.org!not-for-mail From: Andrew Suffield Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 19:42:00 +0000 Lines: 35 Sender: Andrew Suffield Approved: news@gmane.org Message-ID: <20031103194200.GA10852@doc.ic.ac.uk> References: <20031103124227.GA19895@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" X-Trace: sea.gmane.org 1067889588 28674 80.91.224.253 (3 Nov 2003 19:59:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 19:59:48 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 20:59:46 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGkrZ-0006GG-00 for ; Mon, 03 Nov 2003 20:59:46 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 4AC6F1F7F6; Mon, 3 Nov 2003 13:57:14 -0600 (CST) Old-Return-Path: Original-Received: from cyclone (public1-sout4-4-cust241.cosh.broadband.ntl.com [81.103.170.241]) by murphy.debian.org (Postfix) with ESMTP id 6D3CD1F78C for ; Mon, 3 Nov 2003 13:42:01 -0600 (CST) Original-Received: from asuffield by cyclone with local (Exim 3.36 #1 (Debian)) id 1AGkaO-0002rE-00 for ; Mon, 03 Nov 2003 19:42:00 +0000 Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <20031103124227.GA19895@grsecurity.net> X-No-CC: I subscribe to this list; do not CC me on replies. User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154958 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 13:57:14 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44342 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44342 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2003 at 07:42:27AM -0500, spender@grsecurity.net wrote: > There's another=20 > exploitable bug in Exec-shield that I've known of for months. Maybe=20 > you'll find it after you put it into Debian. Maybe not. Suddenly I don't feel inclined to believe *anything* this guy says. --=20 .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pq+IlpK98RSteX8RAnyJAJ4m5vH+1wRoPHoqu5v+SpJQdOTmAwCePKtO Mu0ekElE+xd8Bz2pdx5TAHI= =BGti -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From nobody Sun Nov 9 12:20:07 2003 Path: main.gmane.org!not-for-mail From: Manoj Srivastava Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Tue, 04 Nov 2003 02:21:09 -0600 Organization: The Debian Project Lines: 33 Approved: news@gmane.org Message-ID: <878ymw1r4a.fsf@glaurung.green-gryphon.com> References: <20031103124227.GA19895@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067935655 1788 80.91.224.253 (4 Nov 2003 08:47:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 08:47:35 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 09:47:33 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGwqb-0002Bm-00 for ; Tue, 04 Nov 2003 09:47:33 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C48091F86F; Tue, 4 Nov 2003 02:46:56 -0600 (CST) Old-Return-Path: Original-Received: from glaurung.green-gryphon.com (host-12-107-230-171.dtccom.net [12.107.230.171]) by murphy.debian.org (Postfix) with ESMTP id 965561F74F for ; Tue, 4 Nov 2003 02:29:45 -0600 (CST) Original-Received: from glaurung.green-gryphon.com (srivasta@localhost [127.0.0.1]) by glaurung.green-gryphon.com (8.12.9/8.12.9/Debian-5) with ESMTP id hA48L9RW014247 for ; Tue, 4 Nov 2003 02:21:09 -0600 Original-Received: (from srivasta@localhost) by glaurung.green-gryphon.com (8.12.9/8.12.9/Debian-5) id hA48L90w014243; Tue, 4 Nov 2003 02:21:09 -0600 X-Authentication-Warning: glaurung.green-gryphon.com: srivasta set sender to srivasta@debian.org using -f X-Mailer: emacs 21.3.1 (via feedmail 8 I) Original-To: debian-devel@lists.debian.org X-URL: http://www.debian.org/%7Esrivasta/ User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) (i386-pc-linux-gnu) Mail-Copies-To: nobody X-Face: #q.#]5@vq!Jz+E0t_/;Y^gTjR\T^"B'fbeuVGiyKrvbfKJl!^e|e:iu(kJ6c|QYB57LP*|t &YlP~HF/=h:GA6o6W@I#deQL-%#.6]!z:6Cj0kd#4]>*D,|0djf'CVlXkI,>aV4\}?d_KEqsN{Nnt7 78"OsbQ["56/!nisvyB/uA5Q.{)gm6?q.j71ww.>b9b]-sG8zNt%KkIa>xWg&1VcjZk[hBQ>]j~`Wq Xl,y1a!(>6`UM{~'X[Y_,Bv+}=L\SS*mA8=s;!=O`ja|@PEzb&i0}Qp,`Z\:6:OmRi* Mail-Followup-To: debian-devel@lists.debian.org In-Reply-To: <20031103124227.GA19895@grsecurity.net> (spender@grsecurity.net's message of "Mon, 3 Nov 2003 07:42:27 -0500") Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155002 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 02:46:56 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44386 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44386 On Mon, 3 Nov 2003 07:42:27 -0500, spender said: > Go ahead and do it. I could frankly care less if your users get > owned. > There's another exploitable bug in Exec-shield that I've known of > for months. Maybe you'll find it after you put it into Debian. > Maybe not. This is what happens when you make rush judgements and > choose to use something based solely on who developed it. > I've read the post regarding grsecurity and Debian, and I must say > that I've never seen a bigger bunch of lazy whiners in my life. > Maybe if you actually put a kernel hacker in charge of these > patches, you'd realize you have been whining for months for no > reason. Did you ever think that putting someone in charge who can > code in C might help? Hmm. Comparing the above rants to the emails from Russell Coker and Ted Ts'o, I would not lend any credence to whatever the poster is saying. Such an abysmal lack of judgement in one area leads one to doubt that good judgement can be exercised by him. manoj -- He who has transcended the treacherous mire of samsara and ignorance, who has crossed over, reached the other shore, meditating, motionless of mind, free from uncertainty, and who is at peace by not clinging to anything - that is what I call a brahmin. 414 Manoj Srivastava 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C From nobody Sun Nov 9 12:20:08 2003 Path: main.gmane.org!not-for-mail From: Richard Braakman Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Tue, 4 Nov 2003 17:17:25 +0200 Lines: 9 Sender: Richard Braakman Approved: news@gmane.org Message-ID: <20031104151725.GA2719@cs78143044.pp.htv.fi> References: <20031103124227.GA19895@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067960538 26415 80.91.224.253 (4 Nov 2003 15:42:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 15:42:18 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 16:42:15 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH3Jv-0001qu-00 for ; Tue, 04 Nov 2003 16:42:15 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 83BB71F97E; Tue, 4 Nov 2003 09:41:31 -0600 (CST) Old-Return-Path: Original-Received: from smtp1.pp.htv.fi (smtp1.pp.htv.fi [212.90.64.119]) by murphy.debian.org (Postfix) with ESMTP id CC8791F544 for ; Tue, 4 Nov 2003 09:15:47 -0600 (CST) Original-Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp1.pp.htv.fi (Postfix) with ESMTP id 2FD9A80901; Tue, 4 Nov 2003 17:15:47 +0200 (EET) Original-Received: from night (cs78143044.pp.htv.fi [62.78.143.44]) by posti.pp.htv.fi (8.11.1 (Revision 1.5+JAGae91741+JAGae92668) /8.11.1) with ESMTP id hA4FFkN06455; Tue, 4 Nov 2003 17:15:46 +0200 (EET) Original-Received: from dark by night with local (Exim 3.36 #1 (Debian)) id 1AH2vt-0000iH-00; Tue, 04 Nov 2003 17:17:25 +0200 Original-To: spender@grsecurity.net, debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <20031103124227.GA19895@grsecurity.net> User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155029 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 09:41:31 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44413 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44413 On Mon, Nov 03, 2003 at 07:42:27AM -0500, spender@grsecurity.net wrote: > Go ahead and do it. I could frankly care less if your users get owned. In that case it seems safer to avoid using any software you helped to develop. Richard Braakman From nobody Sun Nov 9 12:20:09 2003 Path: main.gmane.org!not-for-mail From: Peter Busser Newsgroups: gmane.linux.debian.devel.general Subject: Re: exec-shield (maybe ITP kernel-patch-exec-shield) Date: Mon, 3 Nov 2003 16:55:04 +0100 Lines: 38 Approved: news@gmane.org Message-ID: <20031103155504.GA10712@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067876059 26089 80.91.224.253 (3 Nov 2003 16:14:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 16:14:19 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 17:14:17 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGhLN-0004rM-00 for ; Mon, 03 Nov 2003 17:14:17 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 9F6CE1F745; Mon, 3 Nov 2003 10:12:52 -0600 (CST) Old-Return-Path: Original-Received: from mail.adamantix.org (unknown [212.204.216.41]) by murphy.debian.org (Postfix) with ESMTP id 13D291F68A for ; Mon, 3 Nov 2003 09:56:37 -0600 (CST) Original-Received: by mail.adamantix.org (Postfix, from userid 1000) id 3F3FA6B649; Mon, 3 Nov 2003 16:55:04 +0100 (CET) Original-To: debian-devel@lists.debian.org Content-Disposition: inline User-Agent: Mutt/1.3.28i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154940 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 10:12:52 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44324 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44324 Hi! I am project leader of Adamantix (which was previously called Trusted Debian), a Debian based distribution created especially to provide a high level of security. I am also author of the paxtest program. I started writing paxtest, to answer the question: ``Does PaX really work as advertised?''. Adding a patch to the kernel is one thing. Proving that it does anything useful is a different thing. Everyone can download paxtest[1] and compile and run it. Adamantix users can simply apt-get install it. The design and implementation of PaX[2] can be found on the PaX site[3], where you can also download the latest version of the patch. The paxtest test programs are small enough to be understandable for those who have some knowledge of low-level stuff. So it should take a couple of hours to do proper research. It is much better to gather your own facts than to take Mr. Coker's, Mr. Spender's or my word for granted. If exec-shield would be better than PaX, it would be a matter of reverse patching PaX and patching in exec-shield plus a kernel compilation to switch Adamantix to exec-shield. The reason this hasn't happened is simple, exec-shield does not even come close. Exec-shield is also believed to be slower than PaX (although I have not seen hard evidence to support that). So far I have not been able to think of any technical reason why exec-shield exists at all, let alone a reason why people would want to use it. [1] http://mail.adamantix.org/paxtest-0.9.4.tar.gz. [2] http://pageexec.virtualave.net/doc/ [3] http://pageexec.virtualave.net/ Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ From nobody Sun Nov 9 12:20:10 2003 Path: main.gmane.org!not-for-mail From: =?iso-8859-1?Q?Tiago_Assump=E7=E3o?= Newsgroups: gmane.linux.debian.devel.general Subject: Grsec/PaX and Exec-shield Date: Mon, 3 Nov 2003 14:26:42 -0300 Lines: 220 Approved: news@gmane.org Message-ID: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C3A216.8097D440" X-Trace: sea.gmane.org 1067878085 31523 80.91.224.253 (3 Nov 2003 16:48:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 16:48:05 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 17:48:03 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGhs3-0007qj-00 for ; Mon, 03 Nov 2003 17:48:03 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 559C21F4B1; Mon, 3 Nov 2003 10:45:40 -0600 (CST) Old-Return-Path: Original-Received: from whatever.org.ar (unknown [200.85.107.17]) by murphy.debian.org (Postfix) with SMTP id AADB51F72E for ; Mon, 3 Nov 2003 10:29:19 -0600 (CST) Original-Received: (qmail 29421 invoked from network); 3 Nov 2003 13:25:24 -0000 Original-Received: from unknown (HELO insane) (200.251.14.62) by whatever.org.ar with SMTP; 3 Nov 2003 13:25:24 -0000 Original-To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154944 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 10:45:40 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44328 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44328 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C3A216.8097D440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. I would like to point out certain things. First of all, maybe the most important, we have the freedom problem = here. It=B4s CLEAR, after analyzing his own words, that our friend Russell = Coker has a big interest of getting Exec-shield as part of Debian Linux. That becomes even more clear when you see the affirmation, again his own words, he's employed by Red Hat. I won't say here that Red Hat, Inc. would be manipulating information to force Debian users to use one of their products, because I would be = going down, at the same level as Coker. Since I don't know Red Hat's = relationship to this issue, I would go for how non-professional Russel Coker has been with his posts. In practice: "It seems that exec-shield does 99% of what PaX does (PaX is the most = desirable=20 feature in GRSec)" - I won't go on technical issues since there is the a article Brad = (grsecurity), comparing OpenBSD's W^X, PaX and exec-shield, that can be found here: -> http://grsecurity.net/PaX-presentation_files/frame.htm But basicly I am so sure that exec-shield doesn't do half of PaX work. "Maybe we should solve the debate about grsec and standard kernels by = adding=20 exec-shield to the standard Debian kernel source? Then people who use a = kernel.org kernel can apply the grsec patch (which will not apply to a = Debian=20 kernel source tree), and people who use the Debian kernel source will = get=20 exec-shield by default?" - Who are -you- (the ONLY individual) to define standards on linux = kernel security designs? "The plan is to get Linus to accept it as a feature for 2.6, but to do = this we=20 need to get it tested more. It is being tested in Fedora, I think that = we=20 should do the same for Debian. Getting this patch deployed on large = numbers=20 of Debian machines is what is necessary to get it accepted by Linus." "I will make a kernel-patch package." - Again, I don't understand why you should worry so much about some = project you don't even own/manage. Or this is for Red Hat? Second of all, in a technical approach, you should compare all of W^X, = Grsec/PaX, Exec-shield. My personal opinion (which doesn't really matter) is that = of there is nothing like grsec/PaX, they are above all the others in so many = ways. Will be easy you people to see, checking the references, reading the = theories, studying the implementations. References should be pointed out: - http://grsecurity.net/PaX-presentation_files/frame.htm - http://lists.insecure.org/lists/bugtraq/2003/Aug/0137.html - http://people.redhat.com/mingo/exec-shield/ - = http://marc.theaimsgroup.com/?l=3Dopenbsd-misc&m=3D105056000801065&w=3D2 This is a lot of information, but google for much more! Users need to = build their ideas, and choose what to pick! Don=B4t let somebody right the rules and sign out without being aware of = what's up. ------=_NextPart_000_0006_01C3A216.8097D440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello.
I would like to point out = certain=20 things.
 
First of all, maybe the most important, = we have the=20 freedom problem here.
It=B4s CLEAR, after analyzing his own words, = that our=20 friend Russell Coker
has a big interest of getting Exec-shield as = part of=20 Debian Linux.
That becomes even more clear when you see the = affirmation,=20 again his own
words, he's employed by Red Hat.
 
I won't say here that Red Hat, Inc. = would be=20 manipulating information
to force Debian users to use one of their = products,=20 because I would be going
down, at the same level as Coker. Since I = don't know=20 Red Hat's relationship
to this issue, I would go for how = non-professional=20 Russel Coker has been
with his posts.
 

In practice:
 
"It seems that exec-shield does 99% of what PaX does (PaX is the = most=20 desirable
feature in GRSec)"
 
- I won't go on technical issues since there is the a article Brad=20 (grsecurity),
  comparing OpenBSD's W^X, PaX and exec-shield, = that can=20 be found here:
  -> http://gr= security.net/PaX-presentation_files/frame.htm
 =20 But basicly I am so sure that exec-shield doesn't do half of PaX = work.
 

"Maybe we should solve the debate about grsec and standard = kernels by=20 adding
exec-shield to the standard Debian kernel source?  Then = people=20 who use a
kernel.org kernel can apply the grsec patch (which will = not apply=20 to a Debian
kernel source tree), and people who use the Debian = kernel source=20 will get
exec-shield by default?"
 
- Who are -you- (the ONLY individual) to define standards on linux=20 kernel
  security designs?
 

"The plan is to get Linus to accept it as a feature for 2.6, = but to do=20 this we
need to get it tested more.  It is being tested in = Fedora, I=20 think that we
should do the same for Debian.  Getting this = patch=20 deployed on large numbers
of Debian machines is what is necessary to = get it=20 accepted by Linus."
 
"I will make a kernel-patch package."
 
- Again, I don't understand why you should worry so much about some = project
  you don't even own/manage. Or this is for Red = Hat?
 

Second of all, in a technical approach, you should compare all = of W^X,=20 Grsec/PaX,
Exec-shield. My personal opinion (which doesn't really = matter) is=20 that of there
is nothing like grsec/PaX, they are above all the = others in so=20 many ways. Will
be easy you people to see, checking the references, = reading=20 the theories, studying
the implementations.
 
References should be pointed out:
 
- http://gr= security.net/PaX-presentation_files/frame.htm
-=20 http:= //lists.insecure.org/lists/bugtraq/2003/Aug/0137.html
-=20 http://people.redhat= .com/mingo/exec-shield/
-=20 http://marc.theaimsgroup.com/?l=3Dopenbsd-misc&m=3D1= 05056000801065&w=3D2
 
 
 
This is a lot of information, but google for much more! Users need = to build=20 their
ideas, and choose what to pick!
Don=B4t let somebody right = the rules=20 and sign out without being aware of what's up.
 
 
 
------=_NextPart_000_0006_01C3A216.8097D440-- From nobody Sun Nov 9 12:20:10 2003 Path: main.gmane.org!not-for-mail From: Andreas Schuldei Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Mon, 3 Nov 2003 17:58:55 +0100 Lines: 16 Approved: news@gmane.org Message-ID: <20031103165853.GC6499@lukas.schuldei.com> References: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1067878783 799 80.91.224.253 (3 Nov 2003 16:59:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 16:59:43 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 17:59:39 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGi3H-0000QH-00 for ; Mon, 03 Nov 2003 17:59:39 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 740661F5B6; Mon, 3 Nov 2003 10:59:13 -0600 (CST) Old-Return-Path: Original-Received: from petrus.schuldei.org (petrus.schuldei.org [81.27.1.16]) by murphy.debian.org (Postfix) with ESMTP id 827301F4F6 for ; Mon, 3 Nov 2003 10:59:06 -0600 (CST) Original-Received: from lukas (lukas.schuldei.com [192.168.31.10]) by petrus.schuldei.org (Postfix) with ESMTP id A0927FBBB2; Mon, 3 Nov 2003 17:58:55 +0100 (CET) Original-Received: by lukas (Postfix, from userid 1000) id 7A200B83BB; Mon, 3 Nov 2003 17:58:55 +0100 (CET) Original-To: Tiago =?iso-8859-1?B?QXNzdW1w5+Nv?= Mail-Followup-To: Tiago =?iso-8859-1?B?QXNzdW1w5+Nv?= , debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154945 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 10:59:13 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44329 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44329 * Tiago Assumpção (module@whatever.org.ar) [031103 17:48]: > Hello. > I would like to point out certain things. > > First of all, maybe the most important, we have the freedom problem here. > It?s CLEAR, after analyzing his own words, that our friend Russell Coker > has a big interest of getting Exec-shield as part of Debian Linux. > That becomes even more clear when you see the affirmation, again his own > words, he's employed by Red Hat. you seem to be motivated by some personal anti-redhat and ant-russle agenda. you never met russel, you dont know him, you dont seem to be qualified to judge him. besides that, it is no bad thing per se to do things that redhad does, too. From nobody Sun Nov 9 12:20:11 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 05:25:38 +1100 Lines: 92 Approved: news@gmane.org Message-ID: <200311040525.38465.russell@coker.com.au> References: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1067884408 15726 80.91.224.253 (3 Nov 2003 18:33:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 18:33:28 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 19:33:25 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGjW1-0007sv-00 for ; Mon, 03 Nov 2003 19:33:25 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 07A871F5B4; Mon, 3 Nov 2003 12:31:10 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id 59BB31F48D for ; Mon, 3 Nov 2003 12:30:51 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 3FC9C92606; Tue, 4 Nov 2003 05:30:50 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id 032AB7F019; Tue, 4 Nov 2003 05:25:38 +1100 (EST) Original-To: Tiago =?iso-8859-1?q?Assump=E7=E3o?= , User-Agent: KMail/1.5.4 In-Reply-To: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154949 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 12:31:10 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44333 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44333 On Tue, 4 Nov 2003 04:26, Tiago Assump=E7=E3o wrote: > First of all, maybe the most important, we have the freedom problem here. > It=B4s CLEAR, after analyzing his own words, that our friend Russell Coker > has a big interest of getting Exec-shield as part of Debian Linux. > That becomes even more clear when you see the affirmation, again his own > words, he's employed by Red Hat. I have a big interest in improving the security of Debian. I see exec-shie= ld=20 as a good option for doing so with little cost. > I won't say here that Red Hat, Inc. would be manipulating information > to force Debian users to use one of their products, because I would be > going down, at the same level as Coker. Since I don't know Red Hat's > relationship to this issue, I would go for how non-professional Russel > Coker has been with his posts. Red Hat has no real interest in the matter. Getting wider testing of Red H= at=20 software provides some small benefit, but on the other hand having Red Hat= =20 offer security features that Debian does not offer is also a benefit. > "Maybe we should solve the debate about grsec and standard kernels by > adding exec-shield to the standard Debian kernel source? Then people who > use a kernel.org kernel can apply the grsec patch (which will not apply to > a Debian kernel source tree), and people who use the Debian kernel source > will get exec-shield by default?" > > - Who are -you- (the ONLY individual) to define standards on linux kernel > security designs? I am not trying to create standards, just to get the defaults for Debian=20 improved, and maybe the defaults for the kernel.org kernel too. > "The plan is to get Linus to accept it as a feature for 2.6, but to do th= is > we need to get it tested more. It is being tested in Fedora, I think that > we should do the same for Debian. Getting this patch deployed on large > numbers of Debian machines is what is necessary to get it accepted by > Linus." > > "I will make a kernel-patch package." > > - Again, I don't understand why you should worry so much about some proje= ct > you don't even own/manage. Or this is for Red Hat? You should do some research on the Debian project before saying foolish=20 things. Debian developers usually maintain packages of software written by= =20 other people, the number of packages in Debian where the package maintainer= =20 is also the upstream developer is quite small. I volunteered to make a package for exec-shield because it meets the Debian= =20 criteria, I have time to do it, and it interests me. PaX would take much=20 more time so I can't do it. I worry about the security of my own machines, and that of people I know. = =20 Exec-shield offers some benefits and is something I can use now. PaX will= =20 not work with the Debian kernel and no-one has volunteered to make it work.= =20 Unless someone (maybe you) volunteers to get PaX working with the Debian=20 kernel then it won't be an option for most people. > Second of all, in a technical approach, you should compare all of W^X, > Grsec/PaX, Exec-shield. My personal opinion (which doesn't really matter) > is that of there is nothing like grsec/PaX, they are above all the others > in so many ways. Will be easy you people to see, checking the references, > reading the theories, studying the implementations. I agree that PaX has more features, and I have never said otherwise. However I believe that exec-shield has most of the features that we need at= =20 this time, and is something that we can put in a default kernel. If you volunteer to do the work to get PaX working with the default Debian= =20 kernel then you can change this. =2D-=20 http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:12 2003 Path: main.gmane.org!not-for-mail From: Thomas Viehmann Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Mon, 03 Nov 2003 19:53:29 +0100 Organization: beamNet Lines: 52 Approved: news@gmane.org Message-ID: <3FA6A429.8030103@beamnet.de> References: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4281BC2EF5689C9480901B68" Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1067886630 21441 80.91.224.253 (3 Nov 2003 19:10:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 19:10:30 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 20:10:28 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGk5r-0002NO-00 for ; Mon, 03 Nov 2003 20:10:28 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 6E5231F6E5; Mon, 3 Nov 2003 13:10:08 -0600 (CST) Old-Return-Path: Original-Received: from mail.beamnet.de (s217-115-138-13.colo.hosteurope.de [217.115.138.13]) by murphy.debian.org (Postfix) with ESMTP id D6D361F6A0 for ; Mon, 3 Nov 2003 12:53:30 -0600 (CST) Original-Received: from beamnet.de (dsl-082-082-164-213.arcor-ip.net [82.82.164.213]) (sasl authenticated) by mail.beamnet.de (Postfix) with ESMTP id A86A043B0D for ; Mon, 3 Nov 2003 19:53:30 +0100 (CET) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us Original-To: Debian Devel In-Reply-To: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Resent-Message-ID: <4Eo4HC.A.nWD.Qgqp_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154950 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 13:10:08 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44334 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44334 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4281BC2EF5689C9480901B68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Tiago Assumpção wrote: > It´s CLEAR, after analyzing his own words, that our friend Russell Coker > has a big interest of getting Exec-shield as part of Debian Linux. This is the sentence of your mail I can agree with (except for the big perhaps). I might add that, I, too, appreciate anything that makes Debian installations more secure. If Russel makes a (sane) proposal to either include exec-shield in the Debian kernel or - if there is no consent that this would be a good thing - make a kernel-package from it, I can only thank him because it probably buys me some more security without having to do much work. Also, not only do personally I value Russel's work for Debian, but he also is one of the people who have left me with the impression that they are amongst the most reasonable participants in DD discussions with quite a bit of technical insight and an agreeable lack of "hidden agendas". In fact, at the time I followed debian-devel via the web archives, I used to only used the authors index as a starting point, only reading the mails of people that seemed to write particulary worthwhile mails, one of them was Russel. So, please don't start insulting and accusing people for doing good work and proposing to do even more of it. If there are technical reasons that cause you to prefer that exec-shield does not become part of Debian's standard kernel, just put them on the table, but save us your conspiracy theories. Cheers T. --------------enig4281BC2EF5689C9480901B68 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: GnuPG key at iD8DBQE/pqQpriZpaaIa1PkRAtZZAKCrUOlHkjE6F+iCWeuNOKfnFJTgpgCfeoYU Nm9WS1FWuLlI5acNOVf6/Bo= =GVux -----END PGP SIGNATURE----- --------------enig4281BC2EF5689C9480901B68-- From nobody Sun Nov 9 12:20:13 2003 Path: main.gmane.org!not-for-mail From: Steve Greenland Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Mon, 3 Nov 2003 13:12:57 -0600 Organization: Not my strong point Lines: 66 Approved: news@gmane.org Message-ID: <20031103191257.GB14546@molehole.dyndns.org> References: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> Reply-To: Steve Greenland NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067887884 24535 80.91.224.253 (3 Nov 2003 19:31:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 19:31:24 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 20:31:22 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGkQ6-00043A-00 for ; Mon, 03 Nov 2003 20:31:22 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 54BF51F623; Mon, 3 Nov 2003 13:30:43 -0600 (CST) Old-Return-Path: Original-Received: from speedy.private (206.180.152.114.adsl.hal-pc.org [206.180.152.114]) by murphy.debian.org (Postfix) with ESMTP id CA0EB1F452 for ; Mon, 3 Nov 2003 13:12:58 -0600 (CST) Original-Received: by speedy.private (Postfix, from userid 1000) id EA04214203; Mon, 3 Nov 2003 13:12:57 -0600 (CST) Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154954 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 13:30:43 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44338 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44338 On 03-Nov-03, 11:26 (CST), Tiago Assump??o wrote: > First of all, maybe the most important, we have the freedom problem here. > It?s CLEAR, after analyzing his own words, that our friend Russell Coker > has a big interest of getting Exec-shield as part of Debian Linux. > That becomes even more clear when you see the affirmation, again his own > words, he's employed by Red Hat. So what? A lot (well, some) of Debian developers are paid by Red Hat. That hardly makes him Eeeeeevilll. > I won't say here that Red Hat, Inc. would be manipulating information > to force Debian users to use one of their products, because I would be going > down, at the same level as Coker. Since I don't know Red Hat's relationship > to this issue, I would go for how non-professional Russel Coker has been > with his posts. The only non-professional posts I've seen so far are from you and the other Pax guy (spender@grsecurit.net). The kind of crappy insinuation that you attempt above is *completely* non-profressional. Russell Coker, OTOH, has a long history of sane and civil posts. You're absolutely correct, you're nowhere *near* the level of Coker, but down is not the direction you need to go to get there. > - Who are -you- (the ONLY individual) to define standards on linux kernel > security designs? He's the person doing the work. He's hardly defining standard. If you'd been following along, you'ld now that there is currently a conflict between the standard Debian kernel (patched, like all other distribution kernels), and the grsec patch. Nobody has stepped forward to fix it. Are you doing so now? > > "I will make a kernel-patch package." > > - Again, I don't understand why you should worry so much about some project > you don't even own/manage. Or this is for Red Hat? Because he's interested in seeing that functionality in Debian? Do you have a fscking clue as to what group you're talking to here? We *all* maintain packages of projects that we don't own/manage! > This is a lot of information, but google for much more! Users need to > build their ideas, and choose what to pick! Don?t let somebody right > the rules and sign out without being aware of what's up. Good advice. I won't let either you or Spender bulldoze your way in here with your wild accusations of Red Hat conspiracy. Look, if you you want Pax as part of Debian, then *YOU* create a patch in the appropriate format, and *YOU* maintain it to Debian standards. Or find someone else to do so. But you don't get to jump in here and tell the peole doing the work what to do, especially when all you have to contribute is weirdo conspiracy theories and not-very-sly personal insinuations. Steve, who hasn't see this kind of nuttiness since reading the mplayer mailling lists/flame wars. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net From nobody Sun Nov 9 12:20:14 2003 Path: main.gmane.org!not-for-mail From: Branden Robinson Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Mon, 3 Nov 2003 14:44:26 -0500 Lines: 46 Approved: news@gmane.org Message-ID: <20031103194426.GG7894@deadbeast.net> References: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t4apE7yKrX2dGgJC" X-Trace: sea.gmane.org 1067888704 26571 80.91.224.253 (3 Nov 2003 19:45:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 19:45:04 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 20:45:01 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGkdJ-00058L-00 for ; Mon, 03 Nov 2003 20:45:01 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 0D7D01F7B3; Mon, 3 Nov 2003 13:44:42 -0600 (CST) Old-Return-Path: Original-Received: from redwald.deadbeast.net (dhcp065-026-182-085.indy.rr.com [65.26.182.85]) by murphy.debian.org (Postfix) with ESMTP id 9CC291F7AE for ; Mon, 3 Nov 2003 13:44:27 -0600 (CST) Original-Received: by redwald.deadbeast.net (Postfix, from userid 1000) id DFF4064744; Mon, 3 Nov 2003 14:44:26 -0500 (EST) Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Joke: ding ding ding ding ding! You guessed it! User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154955 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 13:44:42 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44339 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44339 --t4apE7yKrX2dGgJC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2003 at 02:26:42PM -0300, Tiago Assump=C3=A7=C3=A3o wrote: > First of all, maybe the most important, we have the freedom problem here. > It=EF=BF=BDs CLEAR, after analyzing his own words, that our friend Russel= l Coker > has a big interest of getting Exec-shield as part of Debian Linux. > That becomes even more clear when you see the affirmation, again his own > words, he's employed by Red Hat. > =20 > I won't say here that Red Hat, Inc. would be manipulating information > to force Debian users to use one of their products, because I would be go= ing > down, at the same level as Coker. Since I don't know Red Hat's relationsh= ip > to this issue, I would go for how non-professional Russel Coker has been > with his posts. I think you're making unwarranted assump=C3=A7=C3=A3os. --=20 G. Branden Robinson | I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to branden@debian.org | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius --t4apE7yKrX2dGgJC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iEYEARECAAYFAj+msBoACgkQ6kxmHytGonzoWQCgjE3s+dXZdk96HKyUH5Np3H6n kMgAn12apkfFsuWpe5ArJkqYzys7ocGf =VQZn -----END PGP SIGNATURE----- --t4apE7yKrX2dGgJC-- From nobody Sun Nov 9 12:20:15 2003 Path: main.gmane.org!not-for-mail From: "Bernhard R. Link" Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Mon, 3 Nov 2003 21:06:48 +0100 Lines: 20 Approved: news@gmane.org Message-ID: <20031103210647.B12990@ganymed.informatik.uni-freiburg.de> References: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1067890086 29939 80.91.224.253 (3 Nov 2003 20:08:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 20:08:06 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Mon Nov 03 21:08:04 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGkzb-0006sm-00 for ; Mon, 03 Nov 2003 21:08:03 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E1C4C1F83E; Mon, 3 Nov 2003 14:07:11 -0600 (CST) Old-Return-Path: Original-Received: from avalon.informatik.uni-freiburg.de (avalon.informatik.uni-freiburg.de [132.230.150.1]) by murphy.debian.org (Postfix) with ESMTP id 7ADDB1F826 for ; Mon, 3 Nov 2003 14:06:51 -0600 (CST) Original-Received: from ganymed.informatik.uni-freiburg.de (ganymed.informatik.uni-freiburg.de [132.230.151.160]) by avalon.informatik.uni-freiburg.de (8.9.3p2/8.9.0) with ESMTP id VAA26426 for ; Mon, 3 Nov 2003 21:06:54 +0100 (MET) Original-Received: (from blink@localhost) by ganymed.informatik.uni-freiburg.de (8.11.6p3/8.11.6) id hA3K6md13384 for debian-devel@lists.debian.org; Mon, 3 Nov 2003 21:06:48 +0100 (MET) Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000901c3a22f$b746d0e0$c90111ac@netservice.corp>; from module@whatever.org.ar on Mon, Nov 03, 2003 at 02:26:42PM -0300 Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/154960 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Mon, 3 Nov 2003 14:07:11 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44344 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44344 * Tiago Assumpção [031103 17:48]: > I won't say here that Red Hat, Inc. would be manipulating information > to force Debian users to use one of their products, because I would be going > down, at the same level as Coker. This should be teached in schoolbooks as paralipsis. And the rest of the mail is also full of nice rhetorical figures. Only thing I do not understand is: If you are currently training rhetoric, why do you post to a list of people mostly supposing themselves not to be keen on form but on content? Especially as I personally was not able to find any content between all those words. Greetings, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA. From nobody Sun Nov 9 12:20:19 2003 Path: main.gmane.org!not-for-mail From: Peter Busser Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 09:53:26 +0100 Lines: 1076 Approved: news@gmane.org Message-ID: <20031104085326.GA15270@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" X-Trace: sea.gmane.org 1067937417 5294 80.91.224.253 (4 Nov 2003 09:16:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 09:16:57 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 10:16:54 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGxIq-0003df-00 for ; Tue, 04 Nov 2003 10:16:44 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C08D41F8E9; Tue, 4 Nov 2003 03:15:15 -0600 (CST) Old-Return-Path: Original-Received: from mail.adamantix.org (unknown [212.204.216.41]) by murphy.debian.org (Postfix) with ESMTP id 9AE421F8DA for ; Tue, 4 Nov 2003 02:54:58 -0600 (CST) Original-Received: by mail.adamantix.org (Postfix, from userid 1000) id 8291E6B649; Tue, 4 Nov 2003 09:53:26 +0100 (CET) Original-To: debian-devel@lists.debian.org Content-Disposition: inline User-Agent: Mutt/1.3.28i Resent-Message-ID: <6WLorD.A.vZD.j42p_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155003 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 03:15:15 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44387 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44387 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! > I volunteered to make a package for exec-shield because it meets the Debian > criteria, I have time to do it, and it interests me. PaX would take much > more time so I can't do it. You cannot do it or you don't want to do it? In fact, anyone can do it Russell, I'm pretty sure even you can do it: apt-get install kernel-source-2.4.22 cd /usr/src tar xvfj kernel-source-2.4.22 cd kernel-source-2.4.22 wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch patch -p1 < pax-linux-2.4.22-200310051430.patch And now you can make menuconfig etc. Now, that wasn't too difficult, right? > I worry about the security of my own machines, and that of people I know. > Exec-shield offers some benefits and is something I can use now. PaX will > not work with the Debian kernel and no-one has volunteered to make it work. > Unless someone (maybe you) volunteers to get PaX working with the Debian > kernel then it won't be an option for most people. So you tried to apply PaX to the Debian kernel and failed? Can you explain what exactly you did, which kernel version you used, which PaX patch and how you applied it? I really don't understand why an experienced kernel patcher like you can have problems with a nobrainer patch. I do it all the time for Adamantix kernels (which are based on the Debian kernel source packages) and it goes in without a hitch everytime. I wish other patches were as easy to apply. And it works. The Adamantix kernel is used on mission critical production systems. I have installed the PaX kernel on a Debian Sarge system and it worked. Any Adamantix user will tell you that PaX works. I honestly do not know what you are talking about. And if I didn't know any better, I would think you were a newbie. You can even disable some of the PaX features to lower the level of security to the exec-shield level. Another thing is that exec-shield is (AFAIK) only availabe on the i386 platform. I always thought that Debian was a multiplatform distribution. PaX is supported on Alpha, PowerPC, HPPA, Sparc, etc. (I think that AMD64 is also supported). There is simply no technical reason to chose exec-shield. However, there may of course be other reasons. Such as political reasons. Anyways, I included a patch for kernel-source-2.4.22 here. It took me 10 minutes to create it (yeah, slow computers suck). I'm sure Herbert Xu knows how to apply it. For those who don't: apt-get source kernel-source-2.4.22 cd kernel-source-2.4.22-2.4.22 bzcat kernel-source-2.4.22+pax.diff.bz2 | patch -p1 Now that can't be too hard, can it? Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ --YiEDa0DAkWCtVeE4 Content-Type: application/octet-stream Content-Disposition: attachment; filename="kernel-source-2.4.22+pax.diff.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWWpD6UECQzp/gH/9QCB//////////7////9hZr8APoPqqtgyqJInrElCQN27 pk7GqUKFIgVRUz3iRRKGz1yenvZze4cxiT3vOO8xIolPRo7O3dWWl2vO7qjmwtw5XXm84zzR 5tL3pcrl5gDIswHgAAAGeltZBEhrABAGewNAAAN4AMAAdA9ZAAAXsCe2gAB6wA9nQAAAAoMg AOgB0AGgAAAdAAAD08AfADAAAAAB9AAAAkAAAANA+UuShoiAB5UKACgaoAAAAABXxewLYCa6 9Hh69aDtlViKoCvQGwRCXswAAAAAAAAAAAAAFsANNtNYU3OPCAFABmAGQDwABg9AaUDx43sA rQJ6YB5MDqmspK0MqpqVD1p7N4WgDQAHlQquQAAAFS6AAK0FAHRoU0xAHYz5SDrlRUgESviH Rgc+toHQALt0HIAIAHpXTABmAAGgKyAHpQdADCWhgDQAAEqAAAAAAFAAA0dA6NDp0AHuNezb B6UKJps7U92oAA9KoBIArQ0AegAIQAFAAAaADdgAAAAAAAAAM+GA9AAAAAAAAABAgA4qAAAA AgpjYgAUAANL1gAOgKqjRQBXQAAAAA0ASAAAAA0AAAAHLcwAAAKAACgAAGgBidaAApIAGhQB QDIJAKCgAKAAAAABkUOjovWAAAAABQAAAABIAAHkAAAyYpAABoPQ0FAA+9lAAAEIkiAPQAAA AAAAAAAKA9A7sJAA4Egw00ICATIAmgJkxNCZMo9NI0yTCaAaTBNBpoAGEpiISEJoJoCNNVP2 k9MhMnqifk1T9Cm0YoGgA0aaDQNNAJVPfqpJSNpAAAaaA9QDQBoNDQAAAAAAAEnqlJIQaSn6 ptT1P0Jp6EE0aHpDJ6m0NQNAyNAGgGQNGgCJEiEyJkqf5GptGKT2hkJtJMaY0o9TGpp6U/SZ EaB+qHlNMjI00CokhAgEACATIBNA0BMTTQRtTTTaJkmmBJmjTSfYf8gVHYkqpPpJElT1CpVU kk2P5lJpiJNN0SfRhE0hps0pUwT8/6LcJuKhFSqrNYzMbm6VJ9YwmEUxMQYlSqVKqSVJwrEp GysVCUSqqKqlUFVKFKipSSqilVKKpSqVCVQqUUURVVQwUilMRiqgaIqJGjSk5tGJGiiUpMFS kwoRUSUkpDFIVWFVqrUTZWkFGDgg0CwGGBwFlFiArQKyiU0MSsUYphsBIlR0H3JVYkxwY/6G zZpjCMsLYiKlSJVEqohMVMVKY/+X0bJB/6n/8YIcKlSkeL9bHNWyP/4rydmmyf52+Wy23uP4 xgqeDZpEdCiRWXW0kRUlbaSVKSWSAMUxSUoRVEFpakg3ducq10krWkqxWkqxKpKo8UVKsqya VJiKFUdLtjMklpSlSpLSWyUUpVQqNKkUaaaY0W2zUAeX6srp6HGegADLqG0bRQG2fvP8j3n8 T8p8h9BoBNI/cHuMGAgfcZCeLZTxK8mHzaHrK4PW2TBsbP7FYd7k3KVH2OVstY4cN3BPicPY qN0qeab2S1bdycP9Ld/gf8HkYpK9Tp0f19d0nsf6nJ3J8THm7A+Lc9FbJUmJKpgwUxiVGCYx UYqpJMVXSmUzJkyZSSQBrLKl0rppMkpZd2N9ulvNUse5SsNmmFJVKqVSKUUqlsrSyllpK0kr KgqlRKpVSKxWlVpVGkFvJa6y8uuq3m7EMpUoDO7mXbu67mdKUpbqXktry82HV11LrdUtJSWl lqShpWKrSViqwwwqlq1KYYjEiipFVpUMFaMTDTGm8ulJKWSUpUklS6VK6lspJKDrKcZ4eXlX itVpiStJrVsjFViqr+4YwqophTFKqVRVI0wipjExiViFUgxUmKSMbNMaVTE7bdNt1c0ruuaa 7rrt3XUm52UOnYzW246pXG8zzTxXlKUJEG0qYQgQQIjEiEGCCBLyvLLIMxn8d6q8kvAqVllU KVKpMYwqhUUoUpKYpitlMVFFlLKmipilIqoxpdSaSTKySgyFViYqalrTTd03S7tDGlU1LWmm 7rtDPOLsZJrru67a6lMYgxKFKhVFVFVSoVKhVINKGKVSVTCpIkt11dXXkkrsAS666668aaaj EsqazTMtxmUmK/7FTZsYRUoqo+pUmn/uf/xp4Kj61VyeCaKq1ZSpSqVU8Snmphuw0xhu+tMq WY3Yk6u9VUqkqqqrJJdepdZS8H2KVdJN6OqXV11ddKya4zJl1dUlklUVVUm2owzIwzLanR9A fuE+TY3KOHJo4bJhjB8H7KuE5Km75Kws5219Q0rFbn8ppN3VThUpVKpyc6u78n8FX/Q2q9W7 62qvfxVuzolTh5MNEqgqd5PBoJ+5K8nrP9z7HuU+1XCn+T/Ju3Y+Kp8myaeLBTcjZWiFlM+s h0IwhYcLKrKSXqMOISuSDRBhs4P31P5ENgOg0O3JA7U7Hf2GkF/4HqwMO1WpMFor/21kzMkt WmlqpSV+FRUBEYoxVyagQgQyIX4yf6/uu7NvStO3TVO3FadumxXSNcrpGoC5q4FzXvsEKRBU EKRBbVWW1YtqvPlz/W+Byenlb6ixPZb5NPc2nst2MfUpY++2qpVV9ip+DSewlP8nC9pLfcvh JfG3Xdt13LeryuxkEtkkkl50qTbqkrdSrthVLRSkCMjCSQtXiQisQhoMzWRjTZsw0ttZbGMY x9HNL/4vTMZpP+j+BibP+9jcpurbpVuJsqYcnJ6mmxsrG7h1dUrCsJijMtlTCYYdWugauZ9N 3C23lLkRN1jB/iaaSpokn62mK0rEkYxN2HTDV0ukpby3W6uGyrJRVViTDTGGkok8GmNCMGKx 6n7mMY2NmylMxhkW0tLFuFdoLpSl0l11ttsluvdda00YVUqsUKpQpSsK+xpmraxWIYpTEqpi q2YRpQKppSkqKjGKRjBWJiFVJTEYlMYlFMVMUwqrJJLEUlKXXl15Ly60lk00qjDSpKpRVKqq phjDTQxLVqolJpSsKwqgUxWFy3MtmApUxExRSmMYYqMSsGMKpJVQrFUldZLqlV1KUsl1uGZV aKMWMtwwpQwqqqYlJUqYw000xWkUaTDLbjGmMWUtvKtull150QdZS8l5KvLyXXVSibZZXSnH W53dykupdKud3cpXDbK61KVKpgVikxDDTFViYxVVWIxhpKlaMVSMY5tNCQ+bGNkxjdpiVpkS FYlwlYlyRhUYGMJJhUqYxMGJkTSySqmk+9WFGxWzDSVVK0rMq0YmZGJlSqYorDCscKjCpop5 dKbolKklJLdZVymMq0rSpiTSlRWKjGGE66W61rpa26y2l0YbjUi3FTGzRippCmMKmFUqhjFY qqMMVhUxKkUsqxSfJctkaTCkpjCYqUwpkyy5dZddbpkrjWvVdJdebjoPylIYURSmmGSZJthr SZVq3Nc1ZtlrRV3a3XJt51eeW5F27st1RMi00as2y1oqqkaKlMGASEYSKS2XdWy7Cy2iBCJZ CiqqiqpgC/h/hIRdr7/H1SpnlnMBX9KWnsaFVouakZlyTYz/2QgIK6qR/V5t/9TdT+Li29PR Z2zx49UK/TC1PTyNK83SNGbt2BLtW0qovd1iMFUsa1mZPpei7fX/70dWVgg0IHvOly82WEIw SGIWXTN4QReeS1pYNSez3f4agjOPO3MMeE0DAnBjUERvc3OoiwUgopAVCD+715sHrGevKJfm ZGUGawpoZKH+/Y8DIziBmyW5fRl9cfVIdtDjfi2hKO5FCkxtUqtOkVbt5cULJjv/2WRoz54e +82O9e53Y1kxVYi68KHsNDTbX+++nuHn99z0W9dV6aec1J7huAbGZpKL2vFXAFz1axrW/3sg 62SjYsi1KottyK64PCJ+ip0gTSSSSF4XRazK+N4l9VO/8ttFRbx1fd13prUquhDFPDhbSHSr BSMJ72Su1uAxU0N0MXZ0QjEJCBK3+m//r/NdD9XRsmQ5UivmPSDk/njaxZcghe+8kyAncoIT lJeEZnlCDhv+8K0sMRzamT8z0yOKgfyGzbgzIx1lO25Rd6Okqg6h4XSp5WY8bPq1URWmFhWq pUmxEopch4B2zPy9TMP/gSAVJqqJSmiVXPYJVdbDQyPZB3BQPUrjssaP3qLyAaOo6GZgpcDX 2fwKqiDeBw1J963Ydc/Wy+49xifYCZkIFQonsW8MsH37/33QpKjKyrIEEEprIDEfbDBLvH++ fTwsjw/yYaz2fP8F+9XFkdMevMeKY72C2wjAhsWkJF0YwUSMxZGFJsP45hZmXyTKrMxuNn6E 19x/OfsQLrOuOtGjSFOtDXyhscHyT+P3n8ynhB+r9zN6fBtpxcKp/HkMizydplrEVV1cjVS/ GjQKiH2eL1aR9SGhJJHHR/XGRtUksTWwr8bU8vOGMTMe6UAogQuQYwYHtRFDqAyh1TM/6fGQ BIg63YPOxREfqIG8vrpUDOjEE+yXZ3Og0QFddiM0j6hSDF5zG7MQzLfwCfuExNUwJV1R86Bq xVy3J8mg/DF2k4OJfFgWWQX8/5vP0X6F673733L3RFLwg992it3XxQlkXVlQ9LgJViBCC2M2 MGKgVUwIAxIEKprBzEE338FaOC1SFRycIYCguyEJfUgGh6jSBxmZoydfW5TC2BJSdUisbeXl O9k4cMzI6cjz1DWsVYkZehEJpZBAr07FaEYWiFq6FUYxKrtiQiUz6s4SszdbUUPU6Q70ID1H XvvqHuu9nprvXRpd2uyp3aupEm9+Y3tltunPVSZX0dtzNKlrKu63Fc9cDRshtYvn6KsiWkKh LSSzL+q1YWVF5VHuuvOFpFAGAE0E1WUKKzZGW9iEn+VaW0YiKqbqqplFViOzcTF656XgnnSa DKWu7yr3QSktFlShIDZfdzZhhKEIKQtbgGrpJVxCYoFqO9dXdo0M1bHVQC06m3YAqQhBWXC2 4MHTy02bV1xI287r1l43jc83K2dZK1e0hNJZOa+n6fHyvf6/GvtN6EWFTL4/YCn2degf5FyO Oy/M5oSgsUakbYQOPjJ35vAgQDnMgCg3BUR5uNbqBAk7ytgJtniXrGZO+f6CHik+5rSPWf6U 993dVPrDFK0ximXVgP5C6m82fnVhEqkUJfFNUTfGA1XvR8F6skA1jdPdI2LuuZopLUV83Tq0 CF9m9qwsozSrq9ZTRRpz7lu6Z6pxZaVggI55I8y6sr/BVP1fLqP7Jm+nYmFgFTJFYNcwErtk GU2nIAOADFEUj2XRiNVHo5nSiBQApCkoOgraFGZYk6XqSCSgOB9lOGvH0aA0C1r63v5lmAd2 /q4IV2UWUgDPHsnUtslHoqo6YwSr5soeJKrbdUkm3CqYoznEWQRru9awDExF1QLjXPVwNUyw +q/1prJ8KmOTMhkplRikxZbpwty1yUrpc+VWtcK8613d1Pe4pN5K4G3Kh3bc/AqagDaEUwX8 ZTQoPxVfIqA3l97Wjqj8Q18yPfn+qAdQapXTSKQmqSD8Gr7kSvrUqJyU5iGHwdRdI0Votmat IV44kMo/R5/Za94yKdc0RslQsl8ZKJN34NeMa+umcQ9AGE2gyBBRChQCXl7yQUTv6o4FTzhE uCvQmB1NDWtF2KRsLkmxn1wgIK6qR7ebcE9tNji29MDCsLbciDfphanp5GlebpGjN27Al2ra VUXu6xGCqWNazMn2PRdvr4dHVlYINCB7zpcvNlhCMEhiFl0zeEEXnktaWDUns93+T2lSz+jx 7hjzmgYE4MagiN7m51EWCkFFICoQfbyzYPWM9eUS/iZGUGawpoZKH/HY8DIziBmyW5cYPSa0 QhbaHG/FtCUdyKFJjapVadIq3by4oWTHf71kaM+eHvvNjvXud2NZMVWIuvCh7DQ0219z6e4e f2XPRb11Xpp5zUnuG4C7yTbPOeYq4AuerWNa34sg+TJRsWRalUW25FdcFgGK4FFRAmkkkkLw ui1mV8bxL6qd/mtoqLeOr7uu9NalV0IYp4cLaQ6VYKRhPezsXStwGKmhuhi7OiEYhIQJW/1X /CUf1fT8NotMin1H1g5PtjYxZcQhe64kyAncoITjJd8ZnjCDhvxhWlhiOhqZP0HnI4qB8DZs wZkY6ynZcouwVCUYKkPC6VPKzHjZ9OqiK0wsK1VKk2aVNWi4B2zP6e5mHmEgFSaqiUpolVz2 CVXWw0Mj1wdwUD1K47LGj+Ki8gGjqOhmYKXA19f1KqiDeBw1J+K3Yfyc9OT50UVf4D6TFfP6 5sN/H9CacRtJ4tBR3Q/9a78x3vjT7wBjYEQv/WO7hHOKJioUhJqoAzADZde23YX9wUuQgVCi e5cwyxft7flthSVGVlWQIIJTcQGI++GN3cU7Cp9GbpDlFCqzICFoXDER2hfCa/d9JF5MP4+r A/NYxNtcXVIPsXl5ebSbbkEHa5lg/AZR7oaKjpoY72ZhnuYjoPqeM49jf+53GkVBebQmCK7C o/lWdf9ZNzgtJotrFnjZFz/FWras5vSMZpfK6NkZYl6VatHWeJez1pr9f7tft9fdHf9WHM/Z +v9S/iriyOmPBMd2Y8eC2wjAhsWkJF0YwUSMxZGFJsP8MwszL5JlVmY3Gz/EmvtP6T+CBdZ1 x1o0aQp1oa+kNjg+Sf2/pP0qeEH4/tZvT4NtOLhVP68hkWeTtMtYiqurkaqX40qBEs5NmPi6 t3bAzQeb5QfF3uA58qMjKIbuMa/LpViALJDEkeohSCSSNFQfrZQyqUJOoqeZXP417vvzvpcP 47wZiH6EWQX6aplsIy3X0L/D+GwJEHW7B52KIj9xA4l9KVAzoxJ9xQakB8nmGUUJ8wpBi8pj dmIZlv3hP5xMTVMCVdUflQVMEdOKu+B1j849AzuWp0Dz7Frosd3CxbWt2vVsGoO6UOU1lQM5 SdXlbLg5oRC7otn9NBw2q5oXojkndYfxmkxHt86uqW/QcqlbmGVY52ABQA5BxOnUtzKns3KG l+UXZ5G90A/rIVKnPL9OfQq/B7lI/R+m55+WrHY020kISxP+5gNFVaDCOJIarvHFR6QkPv/5 UCXoHydfkaqI0pkN7mcgk9IIyi6SI6eyPU4iSAQQSgwe4erXv9H8++1k5WLVp/EzDVyKltpv jKEqTly+K6DLPp4I+Vd6SVbTBUIBHg3hqLS2o9djKnKoyyVUt6cbps2Seu5sM01E0bXvbXbG jZlJlGxqUZJ9zuizzvzN7LfeWq2wjzkB9GODNAKxN6gBw4YGvJT2nAOskkFIiJCQIiQklsdC QU2d1CWRdWVDzuC2b0qm2McmGLCyYNDFpVk1g5iCb7+CtHBapCo5OELBhIIQp/fA5T2OY9Th y3nbx+baTQtpOqRWNvLynkOtGht0dbD1lBIxCoqmXoRCaWQQK9OxWhGFohauhVGMSq7YkIlM /ZnCVmbraih6nSHehAeo6+m2CS0PFaod9Gl3a7Kndq6kSb35je2W26c9VJlfR23M0qWZPaOl 8PPdGjZDaxfP0VZEtIWW65Tt5/9Xdm/bq8K6vy8vNenhHQQDlHG9505PVb3sQk/kWltGIiqm 6qqZRVYjs3Exeuel4J50mgylru8q90EpLRZUoSA2X3c2YYShCCkLW4Bq6SVcQmKBajvXV3aN DNWx1UAtOa5ZsFlVSb7abZmmGS6RZLIYypG3ndesvG8bnm5WzrJWr2kEFAQQhBUoMsmNTJ9p Gwo5IsKmXx+IKdvu0D/aXI47L8zmhKCxRqRthA4+Enf0eBAgHOZAFBuCojzca3UCBJ3lbATb PEvWMyd8/Ah4pP3taR9p9E/Nd76p+yGKVpjFMurAesupvNn5KwiShCAnaVKBpTYDVe9HwXqy QDWN090jYu65miktRXzdOrQIX2b2rCyjNKur1lNFGnP4rd0z1TiyyXAIAZWuIvDo4T+Uo35t 0WXsbN9OxMLAKmSKwbygb8vkyNeF6gWAtVTR+/y1o9vV9WuddUMBplsfS53Meq6tvr8MtW2L 43ymacd3y4HBeNfW9/MswDu39XBCuyiykAZ49k6ltko9FVGqigkfgySspI4qqWSVVWVTFGc4 iyCNd3rWAYmIuqBca56uBcCoJ+kap4YmOGZDJTKjFJixMXLamVGUpXS58ita4V51ru7qe5xS byVwNuVDu25+BVzyruS3U7JCY+1V71QGsv670co/WGvlR7s/4YB1BqldNIpCapIPvavuRK+t SonJTmIYe91F0jRWi2Zq0hXjiQyj7fP80qvzmDrutqoJoi6+i4t8/f2227ekcWH9o2ntXkqy WWHKeD2Prooq+J3TFfPwmw36foTTiNpP0tMfT37f19Y4P5ADCYRD8h7PlDVBEvUKQklUAagA 2/sfHaU5FT0M20OUUKrMgIXcXDERuBsaPy2hj0KB4bVA+exiba4uqQfmXl5ebSbbkMueUeX7 T11+rPpVHT0MfqzMM+5iN563jOPNv2TuNIqC82hMEV2FR+tZ1/ZJu2C0mi2sWeNkXP7Fatqz m9Ixml8ro2RliXpVq0dZ4l7N/ulmAIIAk/kAmNLBdBRAQKAbXezluqxAa/A7w8g8YzTan5h6 tC1x2OzCxbWuWvXyjUHeKHKayoGcpOjnbLg5oRC7TFHMhpNquaF6I5J3WH2zSYj+zzq6pb9B yqc+kjevd3ACgByDidngtzKnl1KGl7ouzyN7oB+BARkad3KH3qvyvcpH4/sueflqx2NNtJCE sT/cwGiqtBhHEkNV3jio9ISH7P7ECXoHydfknaqm+In4M5BJ6QRlF0kR09kepxEkAgglBg5U DNt2oePt6be9oiv17urx2lgr267RneevNud2hvs+fNXvvaW2crhYorucsNRaC19lrlvetc2S x8nu9rer1aeu5sM01E0bXvbXbGjZlJlElsKWyqvxzFqXWeqb1PpUde7fj3QSq5naVi/YNw7I iSb0KTt5/mwLM+3X5AtV7QWprkaOr8Qp/0u+Z+f8QMA/UB/O6gHtOI2mq0Hn8h3jjlyWnqzW lzwt3xobYbWXzyXvXbTW9AXc3eAUfFaPgijpVWIoIjyr9ARVM97CA/QOj09JYRBld+FYBSlx AUtFQ9aD23Di26lloCjxbzLqD+lgBeGVfrgFYic35feNTIBIoTTcQz6kdIPfS0kmJXNXm9Ko sjjjHHJQnCpVS5VVV2SS+ec3s2txNMnfeg9kYYtsv42GRu8/1nPVdcgyPFV2EgSEiSqSop5x Rgls0Oog+eDFyVGpQUKoKaOGfw2p3nxCqwoQxJVYgs3r9VsgO8z5dt3AhYAfP2Pa82Uzy5v/ RHx9btZWfJXr5yY7blcpAiBbtUMRIomlq4fYzBIkaECFFAnC1rS16pdEZy/fATE1sK2OyOYk dpDxofY4cpH6KGjarBPRa0mYINZELcmxIYo6Hd71adzTP4PBsGK7izys27ophFQSnfarEZwC zrJhGu1hN1iUj1ASHV39cAHKYgGLRxZSKPewRdFecNPMAQAG8AZ9hwpZ62ZurJgvsc4t07h+ G1M7KNV4MIQCoujMYboOJQdkDVjrEXc9jh24Ou+sRF1RfFmH7lVPBYFkyVQaWM2SeXnjPmr5 wGRGJqoAfV+IHyAa+jnBIP5ffMsT8ktsgFsLVL6HV9a8aa3oC7m7wCj8DEcSEFCiQIQBiOaa gIqnXqYQH2jz8eiWEQZXelYBSlxAUtFQ9aDzuHS3qpZaAo7m+0uoP2sALwyr9uAViJzfn6xq ZAJFCabiFHSRQgaIYklQS7RfN6VRZHHGOOShODTaibbkElPvX6/8XbzTTJ3n5T5YwxbZfgYZ G74fCeKq65BkeKrsJAkJElUlRPzcX02PmFGD1tbOCE8fXuYko4FBQqgt2uN4TuMOHVDcQsAP t972vNlM68n+ce/1O1lZ8FevjJjquVykCIFutQxEiieu1cPezBIkaECFFAnC1rS16pdEZy+c BMTWwrY7I5iR2EPGh8nDlI/JQ0bWYhOla0mYINZELcmxIYo6Hd8ladzTPzeDYMV3FnlZt3RT CKglO61WIzgFnWTCNdrCbrEpFqd0J+pmbj72C+bn7G5YD52ppZRqvBhCAVF3MxhlBxKD6vXA JC2egm7nqcO03XSyIi6ovgzD5qqepYFk1KoNLPPPbzz4/Y9uvqq3VrW1/B+skDZsAAAAAQgA EkgEkzJIABMyASSSAQgAJJABIBIAzASB13SmzSEZgCaaSDKEhEgkIABIEgETJkkJkCUxIASA DZsAkSAkASQkgCywAQTAAlNMImH6d3ASCZZYQJCQIZAAQgASAATydIAAABIEhCmAhIQ7ncBI JMwATISASLNkAEgBqahmAkAAAAEgkAAJJAAJCSQmSQSBIAAAJABIASACZCSQACEIEJAJCQAF myAJkASS67XaCQA67bthTQkhIAEIAJAACZASZgmRkGZAASASCGQTbTbSJn7yrXNjt6Ndm/AC oCJcSRjPZ5q0aGstWrIEcsabNXapW4CJiJIxmnuS4opr15GpmWvVemYsIOcs4shixqpMJGqJ qpOCEUxVEqSiyCiKXdCesUA6jmBHLL1jymYt4ko3hq6GgoIEGEjCSSxuKq4hcwhcwuLiIzLc TxUx110v79e6/Ffr3tv3bMstqEE1CkkIDBjBghmbpgoD5DAvmOMHpEHy+CNGjLMsmmabXz17 7q+xL9yfqeWt2Yk6P2DZttyZnmn3N2gm17KRGmsxK/yfrNB72zE+g042ttWqttEO7ghIkSSB CEgAABCE/n/f6d1TvJ3GwP0Ot6XmOedV2fhvdbe19qSSUklllkCSSSUpJJKSSSSSSSkpKSRW Oh/9Ps0jycOiqlJ7BT6kKk0VUrdTFDgrCiqaY95jdAqabFVSlSUqqVK/hqMeyHQSSV1fPJJK SSSX3b78+uL5L2vaSSSSSWUslJb9SfzP1tA3VFQlKpKKhUhUKkKTxUYocKSMVEqpPRhiH3ub zP3vySqlfc+wqf1q/ofpTA+CU/mMTqmzE6Or6jsjTzf/CB/dRbEqxYsFPsCHMIesA3A7wWB+ wPpEfIHePynwnMe94Oiv1qP2PYYmyvax4MaPe4vVa1fN80hPrtr4K3eASH3ruAJAAEgACBTM wkAzDZsLKmGzZIAAATIIQkkAJAkAJGmgACSSmkmZJBCU0kxMACQAAABtNos0QgAFTYGUA0oS CQABSgCmIJEpSAkpQkAAzAHxnEPfavuW+F1fcvy3W+e/ZvjeRpp/O9FbJJ5nVwklfU6Hi2ea nJIVUiqVVHgrTyMGKp5p1YmzqFKT/Mne+z+q2qr/OrMMZj2sctrZn/1bjR1OjFSqY5vwbSrP FGxxz55mbHreg7jhwYYwp9pOxuYdz8lck4f4KrRWKr6OP/q3kw7h2duVvNVV/qf53k7vO3k/ FiPWpXVuYP9BO5/8k04TcD6KxUkR1SbMQlUndZbJJsqIqmMYlTiZbX6nccnRzVXJNKbf8iYi vLUlOIn8aKX7ffL9OAM5i6xdVCRKMGRNEZMHwme5E6Ia8gc4roqSnETXRS7W1L12BpXHcbQl QyzBbVJWdzXdUd1SSRWK7rbIxX4q7+a1U+1pG5TRX/aofIowpp1Vjk/7n/U02Ozk4NjorRs/ I2H3vLtVtCfyuYfrHJVT9BiYf2KK+Ag2JUh2ChpSm76nck+Sp7HNwP+p6OEn8qkFSpCqI/aU ObvftSdlPF3sPgH9bZ/Mbjf+FawTYaxwOYzEkCx2aJKFpPPLWJUpbEn+9/KxNK5qdGnRpK5M TxSoaUU8RT+Xuw2Sf7T0ftV3vg3SuqRPUfExOp1To//JzSfN6mP1KfN+xPYH7FPubmPef/h5 honc9En53teKuiex1et0epG58XuYc1SnZ83/Bs7nRHM0xUwdWPkOz1aHYpJP6E+jHwK5ujHV +DuaNFTuK4UkNP5GJjkxJipJVSqP8nwY+TwPIaE8HrQ7Jo6Ozvad4VOY3c0xoe9sfk0jxHI3 abvwYclKrSldGO5Tmm6dhTRThtbZ3tifyK5q2KrFYpWMYmFFVKqOSo+tzSYnyPJ8XJjs7j63 Jw8GI8hA05vuepVSnine+4qtKJyI5typ2Kh3qaKOSjDE3Ie12cPm8Xd+5/FmM/2tH5W3xEP3 lfwIxrZVIo2DFSsKsPzsNNElep9TSbJWzwV7GmPFJsjDcrZiqVWNErFbNHm3YrZpwmIfk5G6 NKqq4CaaT7T+lXsf9iSfnKI/kdj5A6j86krLLcVjKuLVwqJ5ItlsqVTSaMMEUCEUM9AYYCBH jp/3L1f+P/R3M7a5/swz8X7ra2djQWki1PjcUBsq8UVu0uO0q8ZD/CEP2ocs7h6WhCRAJhOw i+0z/J4kpfSNkjDjBxY8U5+veCoVCq9SqG6yGDgjv/v0ExytbfrF4/uhEIYbTMRcFhoC7JiO Satjm1WMVutsEJxn0QEOhbXa6djQWki1OFxQGyrxRW2lx0FXjIY9schabBw5ws5oY9ExsxCE iATVPAi3Az5vElMqUEZULBlYsCp/OI7hteLxa+ZrqscTeKc+jYCoVCq81UN0kMHBHT07RMar W5ZC8dMIhDDeZiLgsNAXZMRrTVtd+TXipmNkg7YFgysWBU7hdgLni8a0FzVYILr7qCrSa2ZF axFA1/otkzYGmSU7yFtX9tizwVuOIx/s0JMWViyqq1sX+l2eyYQarMbBi0mzmRWsRQNnmtkz YGmSUzIW3Ox55q2eGeZJ31mrrMzOnXPVt+d2B4PmrvT8VVgYYpUp6yppUh/ofockjSRwqlTx SGkYQ+t9g8Ftt7W08mYtf97R/if1nN0q9WRcxcZF3EfyJuwY+13bW7Iqmx+1Hcr/Sp/IeIYm ipKf607ng/BN1abub2HxVXcYG7h3pjuSv2tkdDzbio6v/NJJD9FIR/rj1fpH8qqqaU/epPgU KoxWW2bqk5K+KjkpOFK4YVTdTFCqbsYqpNmlYOTZordsxTSscmmhpsrCtm7GlVVV+xjhphpW K3xs0MVSpThiY5qYbtmmlUVKqtKOHJs0ilKqq4VppWJio5Km5jTQ4YYrmwxpiYor2PFGLi1T xPe1J7ba9G2zSzMXGLMxuPQJzkh0HUHMchvhDIOE0H5zmE7hvicoUPFolk+KbbWrbyU9a8W1 2OSu8fUfU0r0bMbvU3ThudnDk3OSlV6j9v7n2P+cfiskQ9ZZESPBOrwfEfJ4nNJztWhatkKW Raktnrf7n+9/Y+gdmHNoOkEk/J1e1SkP9DAMDuUlFJUpCijk9yfnf6SPaJTqlzGYq2/2Py2t vPPhV3DMHtWzvhO91nBPavZaeuspnxtve+R/rP3H3n8pR+Z6j6n7gofqP1BYb4BBYBkazbDy HQdAodK9IJ4zxFgpgyPIeUATdOWJBjFYSJBjFFWy2Q/1J5AxIf/0+hSlCh8k/0p6ImBs2VVK f0D2tGilOCKm5IrkRpsNDRGkP631Gn+hKNiqhpGOj/i3OR1U+ThpyTHJ+t2clKbpuVN2CTq0 mGnIxFUaSkVNMTErvd7E+8pOSO5/Y6nYrsYYcIeQopSHJH+piRgmCkKUlURQqFKOFYiaYpzd jsYbNlQo8H5n8RpydT7A9DvPFHirBUbvvfepwjd3PUj8w+ZJJPtvEnFkvgrsfB3PUjdTh62m kN0ye232ODsU61LWzPy/BVY+k7+mJ51NKl0ySaqaWNULZLX9bse98lPg2f8/bbwdErseKFPW /kO5s/3/1vztHsYfofFs3V0Mbvxe9J9FFV8PC34IeCHvoXFPW+inqPAeDq+pyOvbqk7B9z5k OhwR8+buNO5Dd6KdUm3F6wuXIc/Eti20qqp/a2cn9RydlbJs8k6p1b1e5HN1aTmnNHo05ubk 0dGzNra6P6XQ/lfxPsP+KTWeg/QeY/cQaHuHGcIMAoodRtGk+QsfCPGH6nPr/S7t3btRt/uD Cof1gxh+8OAwwCkPibH9r2lnzt/ocP/BhyfJ/IfM/yDZ6Ho9j7WjH2juftGq2lmZcZLMzm4c lP7W72tDY+o2VRMUHZ1aYPZ8q8cuZWW5cvCP3nZ0TR/S5n952fe5Pm9RwJDwPGubSP7nySId H0OCcORTuVNGjZ9FVzN31vB3nueLd0VVT4uH6nY3f2NlYP8BOkxMSSOxWBCq8g93uyZlXdY3 mZV2FtwyQtuy5P3/HnbrVeV609a1Wr60JGH0gBGPQ2Qgl69C2TE5zkJpJZrNMSDEWgD/EAgd ogMXsY8W5X/04D1Kho956mxo5Gz0yQxHur1dIV2J1QxELpOkK2MtC2V8A32lsKlSTknc5He5 uzTok03VJ6NORzd7fi2qrmjudj+R7EjY5x0t3Y2hkYyGRs4Tm07krsTuU7ObdVdXqVWIo6If Y5p8XIdHW28IrFts7mJ5nJudTdPRh3R0n1YZMzwbJG6OSTY8km7uODdhVadzZ4qrdoSOD1uG NOFRv0LTkdmnycmOad7k6Hcrc6viaTq3eLTwdDmV8XgxpRWySU4VO/t0zM9na3BseCu5WnCV pg/lbMU0wYoscW9XCv+06mOTs8k2VXZMTEfzvY4ebhOY7k6PY7j3vrYRoiqfW2dmkMbn1GiT gqPMxg9r1DzNkx7SnicOCjor3FPQdzD/kqYo71cnZXraU5E7KfgVNj4jGhsNlPY5/6La2Pqf te5+P5W/Vtbp0PY9rHwO52Yk7wsy2vA3aR73NzY8ExN3I3K4+C+Uwcnbo1fdrryv276WPlXM cpXcKtd5t1tq22dWzHsd7+55P4GMMfFP0JyIqoIhQfwD3FeCtHn+X8/8v6Lnz9slqOQWr/te bwiQjG/huvpTVTkmauZfOl1NK83DpPnKW3vNa0c3b3zC3sB9NKU+b0WsVI0hROTNSibZiGrX OrHzh0sRovgzfTfN6sTLXQDq66C1rV0hUmzj6UOi8JSMkDYtLOnpO5OZ1y+sudbyWo5Bavjz eESEY31uuk1U5JmrmXzpdTSvNw6T5ylt7zWtHN298wt7AfTSlPm9FrFSNIUTkzUom2Yhq1zq x84dLEaL4M303zerEy10A6uugta1dIVJs4+lDovCUjJA2tLOnpO5OZDrSzU/0H0HqB9fyeoE OubB0jB5gocHiA5Q7p84fQvwKrGGJ/Ewxw6OyfpG54eFttum5+9//U/HqTq6K6dMdX+ZhJRa LHYqMStLNTU2ams1NTUYy2KLSUVCixKLRLCUVIUWSHZsyIaFJFFFtsSiyKLKKlFkS2JLYmOj dsonQYxN2n5OTT/In8b1O8j/i7OR7lf5z+F0T+Bs8FVXVRVV1OpRpOiqqqqqqvJp/KNkn7n6 VOrD4vFwh4uTzUTH+B7U8U0O97trbbbbbVXTzd7xTke11E/5ihpKf6XXqq2228k5IlHVU7Me p/E45bt3RwqqqpyHNSvzp+p/O3ejoxTkfmfax731OD/rVHqP9RjxadX7nQ8lSio73m0d6tjo cN2kfvY5ldD87kRp+w5PtKnt93ihyT4BzYmMVOrTSpGmyDTBpGkxo2KjSbMT+dzfc09DwVyc gn9R6OavqPzGho8mNO9u3D7Dcw7mm6EY6J2cDh0Kfw8ObvcG6qSuTonmp1Sc2fqpbGiSlBU8 VT+x/qTo3RsT/JgMKKlJKfim5Porri1Mdl2WpsN0o2ThioVUKqFVCqhVIfMNh72ncjRjETDG JJMMYRo000RjGJJoVNNOh7GPxeiI/UqGE0709TodTudlMNIpj7XRzfF+gxzc3qdXLwV/c2JG xUg0lT1VzU2focno9SG6boVKChQr5ux8HR7XNJ4MNzRNJ6Ke0qTEcK3SetGkUdlVW7GOro3S dVT4Pa5tJ/+0fZy+b9Y2Yw22/cMY9JJ4FUr5IeDq0fJ3NPyT2N2zEbGJ7VFesT63ubn876j4 NJ1TxLJSS0lv05dLLSUpZSpU+9mxo7J8CaDvd50fYbP0tj6IKJW71tMcisRsFKjhhg/2P+Fk tjGj+xiHJpwpOShpswxMbPrUfYpsm5+DgMclY5NnDyPNVKODTHmPuPsFV6nJO9Ik7ncj/hv9 sf56+qj+oO3CaFfbBNOnNNMOQdVDqDVCanGpWsxjdhmaPoqrCirqoKLoBeQIBGRi9w/E9T9z 2J1PvPc+TSSTFR7aX2MSaVFSpHwYwDyYxHNKcFRUsVani9zc/S3TTR0KTY/S0dnxN30T86cl jdaOY7knDSUIrcx3FIjk3Y6uxyObZBo0etpX6DsdU7ynJ9Zh7lTZR/G6MPafgpWnQ2J2ck6G h3qHor9Do6H/AnRzf8UnJ1UpUpSmmJ4HM+x+t1TufmfWrobnwd7q6NnR/ImDTq/M3ejvkeFS 3hpp+Wrf43tcnVMbMc1eSpzaYfFyacnm2fYVu6KOSni5ubd+Z7E0Ucx8jGH5KqnebHqRuw71 Tq+z7/fkzMcpbLyTH21cOolKbNk0Cq7mI2TRU5rI1r3am+1stY3FVDzJWWlSRCAxFgyH26S/ geAhsPcVPB4ng2HsU/830e5pKrweQsoscnVPIjcrZKimrLY6BW7SbIl0tfF5Psc2w72OyVpj HNj6N2Pg7x2T5GNJ6K8nJ3p2dFY2cNnI5N3cxyc13q2bMeRyTxbtPc8fn5fTWta2fzPB1Mdn V9bY5tJw8DmrHZP+jmx6nRyObFbsew+x1dybPI03Ororuf6Wncdm7kp1dxiuzs9Hqcmm5p+h 7XobPe08uVu6eD3Mcnc/Q9rmfX77f6GO9P0fn6pmf0PB3DdUlaYx6mmP63sehpyPY9rybPir h2Vyae9NH1nNjg955eVJAAB/Nvlqvav4L6L8e+KRIqlq1Ng04eKaabNn2t3icOT4ubmbFfBU e1zGKrHox8nc9HqbuHqPF5ubyPenNlWpT+Z2T2ezkh3vB/A+nf9dy5d81bbmZbbu0/BhXmxs HDgKGz2+u0ssshXtPA83R9qpMHo73Qxs8TorRTd8mNN2zFDhs4e1j2q0rdjuOCpu5H3NPGuj m6urmdzZsnD5P3PF/iep/c6vwT9bq836VeoHz+eIejo9qe94vPVvi9az6rLHdNWx7XV7TyHV u/O9/O3hTk6uHg2f82jg7zo3dn0ebTgxWypT84cw9OJKslpskebwfi4Sq3VXMw3PrlLNNECW mCa6PI+rul3BnmQ8H3FmBZDwQqxPWrYmk7NKp7VeSpyMdmzc6NMnK3d6ng2acnR9b7XZJ1Si ch0cOrHex3uTd7Xi6K0dDxPon600bP1kd7udn+dwr1ORu+aq4dm7Svc4et1eD3u57XR2e1uT ofqc0Y9SuqujxYdjmO897/5bHB5PM5Orxd7uaT4P0seCOrmjwD7CKklVaqrX3pJ8TAn7klRz eqrbb8Cdj7nzdz4qfWFcninR9Z7h/pSSOHrHc+t+ZhMRJQldHxT1Mfrc37nzdXV8GneH8xX3 PNPU+jshOTudnMrm2bO9O5+06PY2OynV5viNPrdXg8XIxp1D1N3RwdnVNKRpOjaMtlKdVfzL Prt9zvfBFODsrhWnV0dlbHZWnxOT1tnrafFybOz5nRpsnD4GivRUmjwfW097ueSczGMOSbjS qqTRo/WJjTEejyeKT0UivaTlP2xbFpaHkssWWYwbK/O2Y+bTd5u98ng7PrPIaVPuYk9ocMq1 j2N2yP1j5juf7Hqf3/hb9rd5Pa9rFadjFTZshs2Z4W6N01q2vzp4NJsisbuTHoct7cVu4TZw qes+TDq4Pc3cnm3OTg5KqV5NnJU3fyuj4u5727o5urq/zm54O42Thpw5uzhp71NOTZpWP3vf 5W2qtttttq955k4Klc3Z2bvsex9TTyPaHkaT73Y3aPY8zuaT1OiocnsYbW3m2N0DeXr7zBig Z/LJvmweAV4Dri7Bd47xg7JFeDk09HR3nRrlbw9b4J0ep0epoPApVUr4tx4Oj0N/ZbXkYcPc 2ScN0Y7Oryez2+58HY7z9yu50bHk8jxThw3Yxw/a0+b8Rj+FXsdzkY05uj4q+Lc8Tve5u7Pk 5D3HvVKpVPqV8Hm8Txe1j0adHe72lNH8Tvf+r3OHDo+h62jY2Y/W2e5+o8Wj9T1EQfW05vao +p9b3Ozq3TZOidHo5Pm9jc8ne3PR6GO59hphTvPqViqlfiV2dGPm3TseKfoaOpweKnJs+x0P ubuj63Z/A/8X+Ac3VPi73N9rZ9bHg2bu53OZzbH9KHyKh0eJ3OPjsMzB9OW279LdtvySe56n ZtvbjMtxB0dz2voaafwp6nbzt+p63mxzVzd/fs5jvdDm2bZb5JsbOxj/zfNjZ97mfnV+To3d mz7mme2372zZsdVbsVhu2YT8zdhybm5w9b9rZ8lc3N1V+8TH1Ors3OTmOySTmKiNmGHt9vtT Zurdvvs0kbFUqQ222bEbEnuUlRSRGnenZu0wrmfcxp+xyaPU9T8DybPQ8wr7nN+J2dzkx7WP erzbPI4bNNPFpu5K2N31m79TsbOD3sfN8ne5tn9D/sbNHNuxg7KY7kwxPBuNngm7zVzbvzKe Kuj1Pa9r1tnDvd7Tm7K+LT1t38x4ps95R2iQm1iqqiocKO0eodw4hhAfHtJkLQ4sKEgZmWn1 u5w82nNyKftbnH78Zk/631qoqbJ4Poxwp2epg0qOaox+Pue9VVVWSSSSSSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSSSSSSSSSSSSSSSASSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSSSSSSyyyyyyyy9Tj5kcUccI5MbxvHkwjUIQhCNRqEI4o3jhHCEIRqNQhC NRqEajUIQhGo3jeEIQjeNQhCFnLzrM8rg4QhCEI5kIQhCEIQhCEIQhCEIQhCEIQhCEIQhCEI QhCEIQhCEIQhCNQhCELpHyT/e7w73vD7g0fY+9X1vF971uE4e84O98XZ9bqfxqxpTo0xh9p7 w+J7Dm/kK0rkNlT/TVodB8jZqr+L1sdx1OQ0NE9bm/nPUnNu09Ho6OzqnRydDT973uSf5jHu fyPY97o6va953q70qY8W5wrkps2eTdEkNlEHZHV+tVTZ1T1PBpP4H6Xo4PW6pzeLHrcHo/gd nm73ix6u+3c7no3aOTDvTzTm95Xi5Pm7nk5P0nZ5v9x3OT3Pk6uzFPvDd6NK9G7TZ2Q2fBs0 4c35nre9w4Pkd72PFw8zCaT7CmNCPqcMeDqJ4vB3n5/s5OTgeb4Gzm5vU03OGK+Rbbjs/eaH +tPyT0RifU/lTRuppXtdB0eTCNnwch8HJjH1ubkR+9s0nzVhs+L2ps9r7z1ne5OZwrhjTxfa 7NH0O597RPKVZVKfBDD4O5wp5D1MeLk8E8V8VqT4sDEMY8bbyPJ4Nk3f6XiRo5OjvdFK5PHt VuxsbKclcOTho4Tk8Sc2Gz0d7veDhu9r6lV4q9DwTk4V1adHZspp4qcDZuxzbNPwVyNNlcK2 cMbvU72zY/OqnBicP4GnIP5myeL6d1vg73VPUr0afodHirkysrKzZ3sfzvFj9buczh2MPRpX Bu2VsrDyaN3uV3MczxexucPW8Xvac3c73ebHDHVPR7GkTk/0P3hy2t9z97GnrPR7HeY+Th2d HCpu4eLd6mOquE5tPW8TTq6p+f8/rJN27GHidT2va8nm7PaxzPIxsbqKTGj04nnMyZDdpp1R ydLLZ+qpanvVuVyVPWrhUGlKppjGnQ9boV73r9fkeByeDkY4n1MUSjudXg731q7xu8zc0ruM bIbCNmJyV/aepD2vJ1N3c+53E2dHV7mjTvRSrvS2YqVRuwxUex1T3vqeDvdX+97Hvc1bt3re t6KeDxFMabp6nRw4RWnR0cOTqr4PU9W8no6OGnk8GOjE0rZ8udvDgdnqY3cm7hPEnV1NnJXg VPBT1pJ3jSu95vR6NCTkrwcPzjMO5ZDoZTGbGQ6NGj7Q8BZs1Xay+LDydGzxcnbwt8XVXwO5 PNs5nVMMY5q7N3Z7Hc/lbp4vR4P6jve4rmxs/O9Hc6HgeMtWyqepBsqJPrK+b0NnwfoeDZWy eipHwaY81e1+LTxeR7jh0K3dB0fN4t1edXh9zo72zjutmGe9jGMZ/0bdLdk73R5PBPk73tQ6 I7l6YzO45KVmW6eTHgxObqfNOicG5w/xYdzg9p3n1OZ323qOzyfMnJ+s5Hm3O56nmfc/U5Hq 8LbbZ3veew/kfzv4n+p3OZTs/vMPJs734PR/U9zFcj5K5ubZNOiVu3eJwYRQ6j3v97HV63Z3 uT7XRJOjuesPvTDmwx+gnNOho5ngfWc02I8lbsbvk2c08ipTvfLLXG2ZmE+ijZ/xfi9TY6t/ ytrs5nrd7+dsw9HedXmm7mr9sdpFTd3N06D3Kmzq9R+lsdT1PN632t3kn/y+LTTkdw9p1d3l mZkvjbVCvFo2V5NOr2p/PbeyuvZajSHNXV+p+9yOEbm7zez2/vZi2qq2qttttVb1e8ebh6nR 7ngnJ5nXr1OZUzWOT+NPBOSt+PkcjopukY5JP3PJu7Orvex4tFfYf63ZG77HJ+Zs7H1B8g73 kwPA5vm8X4ubq2jvtp/A+Tv77bbdjhO54tNg9D4t1dnJVeD6nkR8VO9/SN3qK3PB9h8J2t8H qY/f+m3xYmB8zT9ryOT4Par2lP9bsebkbJ5vk6OHi7mlOqsclV7nomNHyjCsEdB0cOF7S9np 5+Nq7uWtnwIFQPQ2GzwWdH7iyHYs4dhGjDoRBnRoO4dEbubwVp2dEw3Y7st4VyT4mB0PrbO5 o2NHVpt3214ODhT8z6Jyac3Dk5OysV6PJzcPB4nUr0bsaeLTEabtNnmet637DmNnQro0VWHs V6He6u963edGN2nI6N1VTd0YaNjzYxw7OzSbNOTRpydCsdVebq6tzZjHzSR8bJEtg9jo83qY /B1dGnzftbPN3Pc4dHvV6MYY2cmFfF6mGJ9TSuGPU83J+h3HsejHRK4U5opivm7j73N73DZ5 K73sU+3tb7Xm9na3kr2K8Xe7O5u/lbmz2P1NH2uqY7nMx2c2O5+Kpu6vRwHe3Y6q6OiN3Nya MbPBicmzHJKaT3sepuxsqub6mk9TZwrmdzH1q6HuOzk9hs9WllqaxlWWpmTVslIqH1vJ3HR6 3ex6NH9yo2dHi/R+i3ucJ2dX2tn0ep2PWfMncfBwh4I4dySep4+Okk3dzETW2zRSkzVuLi24 k+p4uHqck6I8krHcr9Lo+95t3k6sV82zHZXc+bY7JO5J3uH8h/yKrc3T2t2lQ9bq3K/BXVw9 6uStMcG7H8yT+n3PsUWr5sTHrc3U/2qx+p4PY+xyeLdjg9z7nm+bZEk/SV5Pi/sY/hPuy3+R jHCUYfWfmdyniqfakVFRQ/hdzk7JufuVWkw+BiNO8xGzarTd623S2GysTCqVzcjmc03K4NPq fm+dtvDzW20qqttlq1SlPk+t9hjDjjEZluE2VRWwqlPork2fHST52rYzEmWrY7m5wqbPW4dz R7G5yU3KeJudng+W9s+jdpKbvY07letU5D5O5zDZs5t4N8TnZZixlmOha2u9zbOljnDoWvXz FVyrc6UvqeTwN0/W+D8nDzcn+17XyYcn+dEnWcreyubSY7MdBTkVjY+Q/Yr1t3Q0fnbP430D k0+LueTs+TwcNDveLxeLXdb82nR9HrdGncYOx9kfEopZ+5/ZVr/Gr2eA/A/BNPmfxjuNmzDh 6nyeZu2Vu9jSnmrkm5ur2Op/BJqyR+eSbquBqkWTKABkEniaQxFzi1FToV0EJQZwXEBWTRAA sJNDSGIucMRjVXVRkmpyzbMsppIOEidyP/A5k0rdD2AfrKF9BvHmA7Y+zwnQUeyWWUXmBkHY CHeD21JgMHGKbZznEPuDdN4HMLEIfbZJUjYobnolaaDZclsrE00R/2Kh/qzANMrgFuwLZVgI o/sO52SQkvz3fQpHBe8o/EQglAYl0YTSRDjY1gkIFxa/2Nn5PwcBycHeqdCu9zbtkxKilSYc JVVFKrFeJ3nDTyfB/AwCveAVR4D9eyH8znl/j+29IPuVee2Wcc5zl6Q52c9Njk7Nz9ZydH95 9B7XDofN6245DdP3/ttmJJP1niTqdnZzVTh/1m5/MdjzP2SRwftiKSswMtqFLlQp+t9wfP+X ZjOGR+tJ/QqpVSSoVSU+89x/AIPsCj9oYCCMPuKCiCsIQYOFMWrixltVEKV9SsSU0wGJQqlV KqSYo+CPq+Xr/gsct28ou+29jTfdkaYtWnsP4Wj6DR+5wfvAHZMg3z2AHOm5+n1/svExjFk7 13d3kJUze+1DyrQEg2NpQmJbbUMLQEg2NpwHpA392P9sCmSNQKYO8IVBRkBSBk0+9/xT3v8k pVVVUBuh7lewr4PWf49e2DmP7f15rffBob75sGWWyeDkMbtwwnIr/m7VfkjzcH/UV4BR6iqx hKlCq/BRfyls+AxsGyVR2Sv88WxacmG7diKVVGKxgqYKKxVSMYYlVVVIhySSVKJH+tWk0p+C qVP+JqIbKKqKqSkqqiUlK3VWEYFSSSogpSlMVSYxUKqlSqpVVWMTEKMMSipSpWFYxGMYTGMG GJRUpUrCsYmKYqhSgqYxiltkpJddXWNqNbUo2WqqUbKLW2xUZplrSZmaQUoElJVSpKqkpUqh StEWyimUtpZSlLJKVP97GFUrD/I0h/k5PvaH/3KScJEK2K9FQ8FQ/2GMKm7EFSZltKf8XCmm lYjyStJ5K2q05Lkq1ZVtbMGKmCmw0YpU9d13dJeqm4BQa3XW9WvL+KhjkxUqdykYrSpXRhyN zD9yJJKqkVSUCpSUkkFKhCoqqopUikkHooRVJJOFR96mCFKqYxSikmKrEookqRR/P/aLR/O2 EH+Hw/ZmZ9P9v1Zmc33vqD9JNEjwChPzISvvabmxyf5lSeBPtf2fV9zU1rU1dg+SoVUQ5qV4 fp/2MzH8TzVVep/i/kNHqaKjow6v9TZ5Pk9aScnB80lP0CkH+CoqvrVIPRSMUjuQnJUOTyNN OaPRWnDf+j4ZmV9J6Wyv9L6K5N+cqyrCrKqGTJqTJWX5L9Wr5a+ze3tUah9CSUo8Un96pOiS FfJiYVNlTFFehhh9h7xK0TQUDgpisYxPYqlRhVFRUlVUJ+pTZEfiVMdH9b+tJ3tNk7lRuwxW K9Hk8Lb7krJ8rL/7tPYolbMKqhW73Kla9k+3w1rNMXFY7z9apu2Sq3nS2tEOwZBvgCxb5OG7 u7EX8QgdgTBQ/WBD4Km6tIpUPrP6mkm7uR5ANn0ZGwCwNdyQ8RRxCsIYH+ovcA5gcj3hEc07 1Oz7WyHNTwQ+T/e+bZ8Q3R0aPYxjGHsNJ0aYhUlFfxpjglUNKGIVVSeCod7zabt3uPgehpMP 4WPerd/2HwdzY/Wcj8GPebMNGGGGGFNKUKnofUr5VcRJ0MTgbuSnJ+5K6tJgp9B2eaNHJU3c xRgpiGKfc+p9HrVOyYnDm5GKpUTElSe80fUUpTqklR7TTIdFeb4H2u82e57U/7k83wd7g8mJ j4orCsYGJTCmMSYSYqiVKwwjEqdB3vUmNg2VVKVXvep3nrNyfArh9hyNOxsphw7MdytFT0RT 5PgxPveT2233YtbJB8krvU72D0T9Sf3uFbOE6BU5PE2aRs5vF5FPi4ODmhUGxTSj5vgMHuei leRNHq2t6pmW4mhu/gYSP/Y8HNociq+LB8SVDvPRyGMFGE0eTm9E4buDgwrGGlMaRVMNMVU+ imybDYwwwww0R72NK9o+BPacJycOGK9Stj4P4He5u88n9isbVaxVbGz2mle44VTgdHersne0 00Vow0mxsjSeL7Hm8x804dCvU7GPW+Lwdwmx+l3ve7NzzcHR5sdyu9wxjGMY73rSqniT3Kep sxI8Hg6J9Qv67LLbLNPR0Tojc/Or7k0n+5ifBs8Vfer/wejJPZb3J1cmz0fUxipXDGxVRubU WmJHqy3ZUPW72JpHJXN9YmPvVOrSe9o72MGklSUSpSoqIrGMMcnce5sw3PW2bNjsYMJ1fYeT ZHUbisUYKYdhoYU0P6j9KaNzsfJyfJ9j9p833J4ne9zzc3yPvP4G53HDerXvfqdDhsI9h9Th Ng7MOaVOiej1leSaHUr9z7XsI/UUKCuFVVVSlFTEPFEcPa72J2VE2KJO5+BGIkjSU9qvJ4MQ 2VJT2qH62kGJ1YG7ZzR0SNk/OpJ0aHqGMVo+5PxfcGncYz6W0XLZpHM+bBu+5TodRWGzlzq3 RWjho3QYaDiEOY6f7JPrKhPDysjpBTvjrPiLKPpPN1E9FSD7H2MB/Q9TydJ+b68Wet79Te/U /9osYf5taXM4P/pTf/bZ9fvhrqM+P82v8yPeMRwC/z63i383zVHfEqQML2DcF03Qttl+bpsJ /AHEEfkLbGC/zkX+vy+nVkfpmOYJKRyGhs/iJgBU093gwY2hyVGIgGQsP9SJDvVtVukjjOvx 5660/GuSvZ3yfHh1N54ZjVm1P3On3uCCvYxoN1p/+ojf/oYV28z4Mqte8wtf3b/7nGsu8IO4 03e2+w6qer1uAFiLgwTXP28L0xHjDsQcMK8ezt7X7NMRYnX1qCjjcyQOQ7osYVa8uZwf2U4e yzL2Q5VHnt9nPWj3jEbwvlreLez2KjviVIGF7BuhdNxh6XXT6fO0nmDkCOkXXMF6iMPTEAeP r7ezQ+yI6gSUjrsuRdWbuj5HTx7/9OHUHZncbRH6z377k1efToLtWoVM837Eg4AlOeXc43x8 hn1Yf9Ds5mQtfNgBltbxYajD0HSAFSVmDBj7C0mfKYSlD9qNn62WhKFUafb05OyD9aNifLvk +XDqbzwzGrNqz7smdttKTyxlOU4z9yiXvEAlbxooRI9wgHOzw7nGsu8IO406PffYdVOzqcAL EXBgmufXwvTEe2Hcg4YV4+Hl6n8dNfmQByrdYi9Wp3R7jZx08tneHZncZCPlPXruTdz8tBdq 1Cpnm/QkHAEpzy5uN0egZ+WHkdnAyFr5sAMtreSpMcsfujBPHJV2ZjxIA75SZNbw+ELgB4VQ o06Ll3slklkZd8ccYYofhqt36vl7fLTCugrfe9p0TEnN9vl1s+iGSrvvG8gDS2TJveGqGoAb 6oUadFtxZLJLIy3xzzgN+uzflv37876zOpLycn3797Pypb2eD9J/K83Plb/0dXg+VWj5nY6j 97Zs+TofqT6yfrRo6J5PN0ej4p5pudPUv7Z+nNq+HG00LVR6RrV2WQR8h+UZw/AplVsRXoHx PvG/J8X0dz9Tk5n51MV+YPa/he4x+d/UafQ/9fs3/v7fEZZZZZJkQPtqe2VK4j5A5AgJCDAg SqT5Hunxq2Obs9ro+T/ycMfadfbbs+Ku9a/Pv2Lq90pFAUH79pXvvw3qtqfilP5Urxfk6OZ8 2nijXW363i8TR9r/Q2aenyt8DoRVUqVTudXc+5w5q3fyME/1vvcJ/2vNhXzY4eD+5u7HV+YO H4urocKD3CIS8eY3jaPEeI9XXQcu/02WkXiAQKt1vmIXj7oO89w/aJ18Y1I64KJhVROK8Pgr oB2MlWTa6AKikdhAB/KSJ0ukIcmZNcgBCUIQo7hPheqB/Rd+94ETEAgVd1NwhrG+DuNdN43i lm+VhG+CiYVUSi796ugG9krK+F0Dpo+RAL47qvmusz5pK+GwM3mZ1dlfN5ug+9cKay3yuz6O EZGUpSlLjs+G+Id3dxmJfiTaALgBmAazYaHex7ODe8Exm51nnlnMdsN8+YsN8xShIqAOP+O+ +tp8T1HylAclE5xgZmZnKAmqkzmsTNZme8ONiXOPS4+Lm8ON/zH3HAoGAf7gytFjCIAEIyHA 3TtbV19W7ud/Drbw6J49T/ptnw3eBxHTgMvrrneOYrz9IJG8kVSCzlJpe9Z9sOsWJByLtvu6 6Q6OjRpauFeh36N7ceie3ofotn7ga8W4ACmcmQDnyOY56hpzpOo4it3RBI3EiqQWcpNLms+i HMWJByLt/PnoNmzJsABlhYwA2KO2DMGbQUCRCahFybAGAgJgc896AN+Wmg0G0q8Hq/5jnybe XFZPd5Y2c2+upVjw8PCHbwd3DzO6EdHfzA5svxpDrz82WcMnYEKjuz5/yJYGnps01wVlIMIM HhBWUpmSeweu6YVVGwdn8t8TZLENLL7ZDH14uPHvUUiqqXKuoCmUBsqOXoIwIF/NbD2bv45N IzwzMyLM3eOmf5vMc8vuhkXmPrS7GgEMQi1NzQhdbpLWq5HXHWGv16mF0xbrg4vxUSiqqrTt g1vD17Hw9prEHn7X3XZu/hk0jPDMzIsyTwVFGl4VrtbCDG8LSJqIgEMQi1NzQhdbpK4j6t7f W2MJ7Cvg/Q8mzZ8HN6zZWMJs+9z2Wu8e86KqqrR96n0NnwafpT4js8UR/a9jw/T14a1rTb0a dxXycni/pH2m/O3o+IAUflk9dPz3I9MjLuR48I8JLvCTZ7OXGVnZg0Sj9ojtH41snJNoK5bp 7cYLk1tlLX+rccfsg+3CfqvDDD+EcXJdtf3/0WjLdYJj1PsxhkNiKGFCVCGgSA3uoZQFD/cL wGz7nbu+y9mPq7MrXVZLLbFo73q65Wptku5I3IRMrxcYa1M5SmwCgr9lerrJVMqjYoYEHYDL UtlttzDKWwxhh9OvaWfZsY4WZhQqkO8AFcYo4aC6dVWfpXeAD7kqIW2LY+5MBoQDlbFS6Yra LsGZMABawuVdkFmJML++K5ykg2ik0Chgw1WpAKRioUADAmtOsIk78t84Jvf5CrjT1Ss2a048 W1j9kuqdY6gMwzK1K70eWRlVHj0R2SXkEmz2d+2VnHBolHxEdg4VsnJOAK5cZ92MFya2ylr9 7c8emD7cJ9F48+Q5oYjV4Uzcl23eHhgOPLhhtOYrxtQnm/TqhTqOxAHv1LXpvxwDjvfqwhxH UihhaSoQ0CQFXUMoCh+97xs/J27vC9mPv7MrXVZLLbFo73l1ytR1Q9SRuQiZXtcYb1M5SmwC gr314cCVTKo2KGBD7UxYwO6uUauurq/P+X5s33fVdRBTMKFUh3gArjFHDQXThVn7V3gA+CVE LbFsfcmA0IBytipdMVtF2DMmAAtYXKuyCzEmF/fFc5SQbRSaBQwYarUgFIxUKABgTWnQESd+ W+cE3v4CrjT1Ss2a048W1jql1TrHUBmO+guQ7uzZLabhxu0QnU+qyFNR0QB8slrm6k39sRoM b1DFCeyxueG8ztIwbjLm0jluSgyqZ9K7QZswycLCOE4E55xGYlRQxQnOjZ3YmdpGbZyzaRzz SgyqZ5rmDNmGThYRwgJgQJSByzO99zf7pFstkWz2hU9pwjqx0fQT6Kyv0aylLJW2yrftV+U2 NtGxrZfgau2y5q6stWVllbZWRSWspW0srKkpWktslJJSqUlJSW1krZSqSkslpkpSWVlLCkpK UpUkpFcMMSUkqilSlVClVSqiqqThgYrZ0NPNK2OGjSuDmNE3TGMUZZaW1JLSlJLKq8GtdS1+ 9SlKVJLLJWVtLSt9VZV/BXwt1avdGMRtRYsWMvfdxCGtvmlV1JSZNuqiPU0kbqaS3aplzTRj WW7NtFq0tVjY2TFNGGFVVUqbVL0umJM611UrqtfptVf/G1b/3+7/S0BcogGURXLLKwA/mRVW EUAqkRbEn5D+I/jT6k0bER9hRJ6leb9CtNJHrVFFRjRhNIqpUkfCv2a6rX7m2tv+ZIAAAAGp qSSSEkkkgZkhJJmAAASSSSSEgEhJSgAAEgBJIEhJIAASAAABJtm2UpmVKkkgBISbNgSGzYEg SSSSUoUoEmzZmaaABJJJJIEmYAEkgABIBZYAAAEhJJJISABJJbZbZJJSmZmBIGmhJmUpJIAE gAAASAAAASABIEgBJJIABIASEkgVKhJISAAABJIEhIGYASAAAVKgAEgAAAAABIZgSGYABZYB ZYSBJIABJJppQoVSqUpZZIFKFKSSSEhmAGYABmBs2EgAElKZkgGzZVlWAASABmSEkgAABJIA BIBUqABIEgEkgAAAASSAACQAABSmYSSAZkkgASAABISGmgAAEkhSgAASSGZJJIAAAAAAAAAS ASABJIZgAAAAAAAAABmAZgEhIAAAAEgAFKUoAAABbS2gSWWAAEgBISAAAAAEkkhIEhs2AABt m2GzGmYZmmgEhISAAAEgGzYBJIEkkkgSAEhJISZgAAAABVSqm22TZWqZgAAAAAAAAAAAFlgA AAAApQUoABJJJIZkkkhJJIBMNKAAAAAAAACQBIAABmAABIAEgAAAAAUoSAZkgEkkyA2bAASA kJNNAkAMwJAAzAAADMkAAAACQCpUpQAtlskAAAAClMwKlQAAzCTMMwAAAZEGYBIAAAAADUql QAAAAAAABKWmwCQzBAAAAAASGYGUCAABIzASAAAqVAJSkDMzMzNIpmZmZmYAFKSbbGrKtkEg bWbWG21bNa0KtK1Ja0ra0tbaprVqxa2xtrWDM2bCpUArKzMqVAAAk00zMwkkkIAAtKlSps2G lM2pqgNmw2bCDbVASGYCQAAAAAAAAAABIAAAAGYAAAAAAAAAAAAASAAAAAAAAAAAAAAAAAAA AAABSgAAAAAAAAAAAAAAAVa1dbUWqbXbQkMwApQpQkAAJAAAAAAKlQCWyrbq1ZlTK2umJiWC oUpKUoVE/WwYsEgkEsRWhKYMVCCEVWmDLLLLLAss002bAACpUAADZsAAAAAAAAAzAkAkMw2b ACQzCpUAJCTU1AJCQAAAAAAAAkkMzMkBKZmSAEgAVKhs2AAbUsmy2m2y1VRNU1NbbZRmJGaa 0200SGstmS02lliLC2hQqFkLJCwSyRKbRKzaWWa2aqaJAJCQApQMyTMAH/izIgUAqoPYChFa RURzBKVFwIPnq3JIOyUClSQG1W2gkCRtNoIQk9+tqp93wn8S/Zpk0utbJBpssq4KoisVWEMZ VwhhUkqklULJtttBoKtaq0aCsILeFOQqlKLAU7oNSN9k4zhqwzE1mmrDuN2xSKo3wpbWvktV VwAkgAAAAQgEAD4XcAEn7N89819mSD17EFSpUqlRstbZllTAIQhNUwvUMGCii29j77bGhoU4 dcSQySA1NTIgzEZSEICpqSQjVpqSAJEEhJIx7JZ4z8esaPHwZ/k4Dyc+inacoBpJCbwPbYlw cSF0hWN0fM2Xj5nVshjlYqXpQgG6KE5AZYJe999974lJ37rrqXiGH3VjVKxrWFaiFawmAGdO Zw/hbt0dSfUfp+FvYmPow8E7OjudD9jHuf2vzPN2dldmPYY/9n8xw73yHqeweDyfvV1V6ik+ 8+j2+drLX1W+Zp/zU3fud75epsbGI9vEuaS4dH5z0RxDQ/8hpC+nbbaSX6mkmkkkhHpf+v2H V3dl/Hm/IcUg0WQnprJJKSF8h9BrSX0YkaSqPaZE4mS/Vl3d2XfC+3r/XY7t3Y9HvCkeQt94 SSNR1I1HU8MWrOp8jwf3PzO54u87HN3tKqbJ8WJiqrTyf0vYx0Vw70Y/oDnq3q4TxT+9j9I+ weDSppR/eeT4v63e9rscParm/QfQqP0PM8UfR7n+L9b9Dq8XR/e949h2c6WuE7ntO9jzem8t nA7ibqxj/Y+ROrs/Wr/rf4Me47D7z+F807mlR9h632HzPUxtyq2NHD7TTmr3KlJj6j72x9XT OFy5rWtLlzHBNCV3P3PuftO9/AxyTd0P2n6B+t6ul/ZcuetzeDo8XrY8n63kHrbDkPR7Scng n1PxadE4YnaT6radXNPtfc2YlOzdyaQ9xRuJMPoPylQo8zZ9p3ITpjaBcjb/APQNjuUVur7F cmyu9/rfU726pX+xw+p3+f7szNP0VfofY+SscPrePdbU9hXqVJp9Rh6k8R9HocG7v+dvo5nV OH7nibu7dap+o9bpO+2pbbPN7Xk/7nsdzyeTm/W5PF6eqWx3nyeb0NjrWZjPvfR3MY4Vsrm4 VofY5o2adysY9Tva91vJ3lP3Ob0PFOT5vNT+E/J7Bu7h6jkmPeej6nm2d56nsPI2PZ99vtZb didyY00UdkrvT8Xi5PkrE+Dk4adn4PNsdiv0qeSh1J3pubW2Vctk6OgbsR6jsm7hWn9VWG71 jeUWRjmeDqxsbFdimj63WdrZOD1nNh8QLx8gglDHdB3d3fcT8QCB5iIKk9gT93tUKqiA+8df rGKqF+AVN5Mhs7fBVWA6AwDAAWImYxHoHGUG/vs22/c9a1qzTb09hM0L28zesatzWMya0Jc3 ra3sW95rWNW5rGZNaEt71vW0TrkeG+r2jetx7N794zRo32F23yzqzXbnOm9i111Z1Z11znTs 0cMOFrNJdXd2ld665q1t5mZaz5yGjl7Wnudq0amLT1NVs0r3rtrk7PnOc1zm5x7EcNvUJJZw rZYjY2lgzkSZwOC6S0VyucJVpO0s4lIJFwSOjZDcSQ1bbw0M16HQ62JipipBo4dHElhw6MGQ hDRDWJYYMwsww0diAg4QRgQwYzh0WQIQ6Nmzo0bDYjDRCwsOAjZXArm04NMU2cGzTZjolaac zhVYpw4abppwpu5tOiVw4K5nJw0dFdCGYaNmzoIDNlmzo2dAbNmizo2GhmECzDRwR0WaLObV 44pMNmjZCHA6EGhB0I2dGzDR0Qw4aIaNBw4Q6OghDDo0haDRDDZCHDhA4bLNQ3eMV85xanNc 2KXayzS5rrrqO4bS3aWa0LMj1sk6Yr610tTrXNil2ss0ua666juG0t2lmtCzI9wLOjo2cMLL OEL1x9ZT2sx5lPNB0dHAhhsya2iRxE7HYPifpPUO4fafhX13uvV921+T8iRJIQkkJCQCQkCB KUAkyIAJkAAIGZACQJACASAAECQkiZAkpjZqytIAJAAAAAAAAAAAAAH7Fq7jrW3761TVbZWS slbd4AzAGQzTIGQzTIB+W3+WvXtqtsr29gAAAAAAAAAAAAAAAABQAAAAAAAAAAAAAAAAAAAA APnsugAA81/K2+mtr5duU9jHtQ0e1qANj1BPc3bKVshsEY01Obk/gPmn/Uo9G85qRXSJJJ0d Ehsh2VoocnccmgclJpjBuqPg5MScKR9DpPM/iNntfrUgklTcgkno2SHeqGnRj5JTsqT6ILgU IJk8hNYTgAEwL6iCpY9AUxH3FAeoxiSfJKR6k/B9aI9j+gqYmiT9iMEjEkipCkbHuR0VNicI kPi3YQcJDhw5qNJI5JNyJCjdRE0JFRpIojEhOTSpVHIxpJKkqbHmP+DY2TZBhuVOFKlUKYbJ JskoSclImjkbKVNyYSpVKYVJilK3St1KSt2G3wUV1lKqinJibJSlTTGSrJMVVFUr8LbpWjM3 1mrrWYwaVVUlKWbeG7caupbc1425rnngq63kkxWhVSowUxGMi20usmZk00YlcjuBPt+23GZb h+JrWnV6no9zGMdzcP6nYRz6c3wcnZVRDbe2222223m9pyJ+h0IGyeTly7I9H8D3PvftbnQK 2bo8TsI7hRHine+54eH9T607HgkEk6AnZ6OfO3TxgkmtW9zgRrVttu3WZAzWX70fM2+kW7Is NH1nTL3cQzhVF03zIdg9M761rP7a/WxUFkFzLg5rDFHzN2cWzun/B/0RUVUZtrOGedgZwqiy b6yHYPTXjWtZ6667FQWQiuL4xUXYti+t18tTWs1b7b19KVm1PkcUjoZ5HkcIWUz2mCIfQM6N GxHBmg9phwZ8TZWjt5cvc+vdk0LU1Nasmn8Np+qcTn4nxBGxhR/lEFHDubE/FhWnVppsz/1F o7zU1ZX423jrmZ/Q3No6xzHi5JCdL5egyMRhRiHlM7qS41PLMspCXW9Gy1TtGjUaUVNbX4O+ PT44kjEaRjuWkhSOOY8uCckGrjcVrIORy22ox1dpxO0raTg7V2iDy5kZacaSi1tamPTiSNI2 jHctJCkccx5cE5INXG4rWQcjlttRmSsxO08StpODtXaIPLmRlpxpL8w0cdNWHQbrYmmUkWh8 aOYhoSsekI1cHIzlo6UWtanRiG6asOBquhNMpItD6aOYhoSsekI1cKu6NOIapczzzu9BRpBU FdRYKgrCCDh3AA9D2HyiPmpttwQwicUjiQQjTSv7yfzPgr8ntfI3Se4k7HzNj63wHdUvrG/a pHFPYWRCtJHuS/MYfSf1E5z5pJOjnTG7pJYW1bhGo9H24l0UtvmiaWLMwmJ8FxOD2oK07Haa 6RaurkatEV1cNX1vVvtmres1b1nfvTklSdPTe3nd2djp6lxKNneWRp4Pgu+duy7vF2e29O+7 s7HZ6lxKNneWRp4Pgu+d+y7vF2GbGM0Ms7jLDsHVjhps0qtMYdmmxpisbmOZXZu7OquzG6vr H3vI8jze95E7j9p+CP4X7LPkr5KUslSlKUpJJJHIfF+SkoU7z4vW2d6f2h6ceeZmZmZnYxyf EjRyIbPqPA2P8x+TqnR6GPW+Z7SWlSLPnH3pKkqSCCbtRCjilCbbpLybeiH8u3b6pJOuhKiK k286u3qbOywgt73dvc0bWEVNUYkSkNLl9JLO7GYDVGkiUhpavSSzTGZ37iRL5hOr75mLvua7 60XchJISSHbvmZhJIS72d7mtE733zMXfk131ou5CSQkkO/fMzCSQl3s72H3iLNmwh4LPBhhg jwdENHg0aCyyECEIQIQhA8HgwwwwIQhAhZZsPB+U2Tx3AWDzhJmoI9q1DLIheXQ8H54XLV1u tayvTJVeygCznKF7NQRvW4MsiFvteD3X3LV1utayt8lWrCzeYJT0uuuthxHMXK5y65zYLjdN JumgPiHvKoo0AYQPmDsEoiSkbckkkkA+oPlDzDDD6EnrPkQ9DvclU8HsQSTufUjp3Ih5k6PB hNIY7CH2pPE8SpStx630D73oeb1JyOZsk8HNsbFKUpSlKUp3uHU9HZwk4FSpXJ0bvcfM8T7n of5iIO+wSLYQnUf0Ffc+jocO91TgiopHjIwsi4tESlS21JW6lXSrSW0s91uiaUK0wwxgrETC pSiy1LaSpSpSyu8Ot5ZIklIqpFaaaEaFEVKVT+lH7X8Sp+xXqR9ZPMczs+or8B+D5Me5hHxP nSVMtxtwdtoTbluUi7uXSLssjZKbPk9wlfYOjqUpSlKUqUpSlKUpSlKUpSlKUpSlKUpJJSlK FKUpSlKUpSlKUopSlKUpSlKUpSlKUpSlKUpSlKUpShSlKUpSlKUrkPtSSPrVCqhBw+gcDoN3 ibBonZzgfH4nTjzxAjvO8y887zLy8uvLJ26Kqquw6mNFKVjds3y8rlzGGxK23LViGmK7kpF3 cukXZZCykFp3D4OZ1HQQ3adSlKUpSv9rhyJu6j8HkJDYdh1UHUbCOrClKUpSlKUpSlKUpSlK UpSlKUpSlFKUpSlKUpSlKUpSlKUpSlKUpSlKUKUpSlKUpSlKUpRSlKUpSlKUpSlKSlKUpSlb BzJXA5kOQtXxqVbqlSr46oACWlVCjEVbbbbVbDyDyUHifmHQYKjqjq6OrqVVaZrWZjFqtacp EjlIhBkKQdzwCIWCEkkIZBSlKUpSlYNN2Nyla1boiQhJDjlIkcpEIMhSDexIQCEAeANa0260 IQSJSJCEkKSSkSOVWmmNJTdGkU8jkmPAR2PMdRhgdu3Zt9hDBDiTIkISQ5JSJHKRppjSU2GD oJ0HMcDm7xUjHJybhsNW2SuY5iJg7mzcd4UI5jcYJWzmMGJsSVw7zmE9CJIOyif+BX+CpH7C KSUjXtQIEJfk6cYkIFUYGFkxVYwCq0YoBH/2pI01iSGqQaeZxHg5jTmEMCq9oH3n0H3FQraW /6ORIDpGLMyJAYuxsnCdXV2dzkjZP+KUP/Inc/+Gng/gUqujmqq2WrWJTiZS1shmZImWDBEF QQEHwEhYJjxQeQwGj5/JmZroaoszNoCFEjVpYV9xwZwqGjhhhos0WbOELDQzhw2CLzG3s4cL O5XVUyq8xFbGHkEi9RTMZFbKxIkg6JSObGW3TdpItV3PVx3XPLwDQxLFQGZZkaLCYJSxtMyE UgGhiWKgMyo0WEwSljaZkIry12q2yiattYxXRWzZ3NG5H6UVIkg2VssrQMZZR/Kv5UqVWGtc 353d3fAKw/QWaI7Kxs5sZq3H2BX3MSGP6n9K1ZKtWPWpzOZ/tYVBVcJp/8laDZT/qNjo4dlO SaRUp1G02tnM7lKlT91XZNyGFNJpvyWqZFWtjG5sjGzdpjLatv7XvbvUnhTfMS0zOCMTYdFF T7x+tyNmmla1bXDHTpb6O90dW5s4bGngbu9G5uTow2KUpo4cIm7d9SCSdjk7jvUrTVXc4ckn cdmBsephPB4vDlFsOZ5IVfCpStdTV0tJ9V9UkzMwfOk6iUklQ9yZJJJGEYiibjjvMeE4WsbO G74SfFEbbWjipbIkY5klGRFttt+qQmzE5GpNlUlOxOxOH1JJIbpOYlHZwTgmnNydHWTsEc3c 81eLoxUSeDY8PBSEbIYR1MVEq9HVI0+5zIzudWRJJGjmRzNbpzepNEcQB4OHerTmm6Peepia YYh8XYwcnmPF4upwdzhhy8+SSMN3BE8XLstTd5GyRyVI0O8bJyHJs3cOA03QTZpNOCYGORwE dkkc3ZVeLq6jyN3cSqVQpU6p9LXeY06G6TSkiTemJD/mE7pMsGhmSS0jBmSPtpakcH+Buhum ZQcPzkhwBYYF0O3KI1KRdTIxBJAZEgrIrIifgQ3w/AT7Qg9YOTEqo/MqepUdnU9z4GB8Sj7G 6DbAX8TnPQQhYT3yUI0LACEAg+EpDFJJiomKkUqQoolGxjFQlStMYUpKVJSqlRI+t/NvVW6R slVUQwowqJSUhMKSqhVSImKjhSH8DQM/6FBW+IbYIQXfvRKqjx6q6ruvyn1B7RgGK/jT+t// x1VKrs+xXeeEhN3JXM6t07ejitQ1RuOIMrFqGI3HGgOyQE7hCESfw+pGJaWFRjHV2eToxqy2 aOFEIIYwNng8+6X1H6yHoCxKHj8D8DTSQjDRANnqdFlkNE/Xv2bzeta1rWu/cY+UGqqqklCq qQ7j73i7keY3TglLKsqpX7wfajZJ1d7xVyV4ubwftfR+5+5VW22280kkO56OSqxP5FR+x5sT hKlRVqxFT/m+4PHo8m7udyqtt2O46Hoj+8UfXo2NzvYxSvi2acJIH6j1myKpKr3IHve9ykhD wHgOzExpoVK/xKxFcD4p2K7jd1RMOEOGmzubMPgjv9LdmyqlUqKUV0HU6uibJSH+LT1tnZXp XR7mNmmHMr2mmFKVVaYw8HZ8W52RUnMfIpyexXRVV9VMcnrOrqmzY6hVY+pybO5DY00phSq9 bkRybG6HwJpE/Qmk0KTkjQ/U8nZzbleRWKrkLZLZ8nQ6t1SPvchp5ur0vXMzybsVPW5NNnQ3 Kj4Jsejm5ODxbmFUpVcmKeLSexzbo7nR0cGjyOVNOHqkxhjHRHST2qhUryq1EqgxjR43tK+N LZOitWTayMlbUtk2VqwOpOb+J/C8Ho4fY73vJo/cfFP2FU71JTCmGJw0w9atlRXizGM/4Dmf Nu9b2hy64dDVazPhrMn9j2vzj9ApP85pSuT0frjxWK6vQ4Y+L9jGyvufkwcOT/qd7wbNxOc+ Vn208dmWxtZtTbZlr7mOCnVX7Q6ne/gbP4H+bz/bnRszbbNm6lO9id5S6sZ8Hfo2sbbNtTZ8 OitcQPgZayGZQMvFkGWHRXc9x6HY+UYhfBJNKmzD4ObY3VNnBjErkw+x7XZ4e700SRejY2/p MLNW239p7hFe8PwLLOjRDQzgjQzBCOiGiBYzhDZ0dGHN/dvtd3d9pnLMyujCoZKkLJBJKsjw OST0va13oYLy+v45E1qtsvrurmtSSabIk3SJEUVJKKEkocz6G7uHD86eLo5SQjh+KaIppsUh 6P8zYeBRo4SclRJ0sSSR8eZ0c3DsKqqUquQ/+HqH5HV4jm9jyR2Pw6o73R+vqrq3dHU7MYd7 wYcoiJJ3lIJJjZsqqVydXV1TzTZ63J2529hWlVSv1uD2GzY0nijHVommyVKlGybu9zbtm7Gz SYpWsOTwburzet3uTDt1t5K6O44TkU8lfJww6s+Nvi2aOrDq0YciqaP9DDwdnJXMObmVVV5q 9DmeBXZhwd7odXirsG6OGx1MVIczZjhwrDTFMNJucWHTMhnokdFf3vwbvw45L8dg7s3323xd tBvm2qSc3kn4E5pFexzFKp3KhlXkkk5vRMdHi3cmfafcOafNPsej2c1dJkl8utNr7z03PqV9 TenjXp43PFerNrrq72yfkTwPyJ5HNyd9tnuOmOj7GzQYHR7RCIcIEDD852Pzn5T6/ZG2rSsZ Kivm2ep5HkxzbOZ6mOhzeCubk5TMuXL1Y9Z1gE3QbTeWWyyy9u33MCORs2dWO5jd73UjsfeU Ycn2q5ODTkrCfafN3HZw4KdKxXPh3n+p8VU9r+lU/hP9qkqd6dXD5Ob7X8TmeDh+hM9dsdHu eZ2PiFfAD2HqT+1JpJtttRJkUI4oRwRDTCR1dCnyO90cVZiJ4E6Kicx9TTcppu8O+3s7Pc08 CaNisetNnvfJsh8U3cnJSqrHSOlvJ0Maaep0Tm5nJzYzFqsOTErZu3exu2VwrHzYclNJ3b2y uaNNkxzTqYdHcd760TqqRJP/yqPtV1627vc07i6q3sY0nUNIPcHo8Hk8yKqHRjvcD20Xkn85 O87E83oxuR+fKt2Uf2Do+071YI4fk+4PVSv/Rr+fnprWtn/e+SP1OpHxcKr2k3iEVVaE3gl8 NScMCs6xdSYgVos19R2frJ4HV1JzVZ/TbYz6LR0UmpTVxMxaNKTUpq5P6mk/Iep5Fbu5/Q7B jlP12XyT0V3479x6N30es4N06N2zon4MLDRwTkZFIyGw/Wf0B0WIswqq1Qb5MhmT+QkhJNxP JQg+g9SebE5Oyu99Hem56KPa0xUnemGJ/cVhKfe4ex2UxsTxOr3pNJ+LweJzOjSug0PUrGHJ w4eGreRWmMHDji31t9k4dCvMrsWYM4bNnY4AYBsRsgO0tnuINyTkbNMVs4JUrq9vdbs5uHD+ dSRJ3jfvt6tpNhzFaNz2Ox3urwcOHg6k3hdZhpikQ2immKRCjQcpsE0mQr9BudTT7zTcjzp2 dXD6K4lWfB/A+96/WT2nDudisPqvf7Lkm22a2uSbfQr7jwTZU0CPQrzPQ8Hjxu1I4meB33bb LPMstJI7myzgwRYzYjDBlbCzYaBh8ojhsgaMOCIWWYX03qx3buxkIFGFAao3KLLPF7E4cnJw cMcmOHvNnb2NJp2aVXvVSu7tbp0VsnDkg6qkOTk04bsVwmk4STDGU00aQV3tmKrsc3NzdzqY 4cnQSUrRwndXJXe7nBBzczwO53dKtxOWra6HNDm3VzfcjHonk8TTudXJ0lbOSeBI5FYH5HJ7 DY8n9R4vgw9h7D+t0PPn9eZ362GUfF7hDFSRJXcrkqRio91bW++zGlFrLdWY0qVumE5Ozhs+ LcbmiPi0mUryXS5Pf3Indyvn2MRP45fhPB8hnhjb8dm32J86S0l0M0YMe0sIIhs0aEcDRWCD DRw2WfA0dHDg81kkiBmdIS2FFQwqimmGW7thdvZVFVXoWdOZyfB97futj6J3cqttWnD5K2dX ed7ZuVSlbOjdWzwVo3YVVeaPcY2uRcq4XLuberZYzAEl0dqWWMxgJJZJGYwEkzMSMxgIxgUV VVbbVYKMGCYLJZJAJJZLMCwEkjMgZgJLJLAAJLKuS6H2P4X8afapzcmyePhb7Hm8Hme14OGj wUrT1vW3et61VjHDh3KmJyPvY9RW7m5u9zclO90SNlE4PBRtReGe3GZ3m5se9PXN7L4t0+18 1cIQ/pUdT1nj9mZ42NeOzW1Na0nm9BHJUkmGKYnpctvFoaazMarlvHLeLQ01rLLYM7/m+t0f +hv/Xb1TZXg6tz+53O+r3Nj5/gljS+HEvUkSqzRoh3GbKs4YbCyFmjZorDZ8x4GcNnR3EbNJ c1BxpyDo0DZ1m1l3IMjd1syKyzdu7OztJ8E03Hu6IWaOFjEWeBFiLKR2O53NgzwbLJscN1cn i8Dhw5K0c3Z79lVZ4OTo65b2d6tnc6m7ud5Ik7N1V3j/WrwRu97EdEeDD3GnKd/3MmY7Hong qqFMfmMc9VPYPSVJEUVPLxTB4lSRFFXmVCupunI/7k/cnrmrC0lsLYdlP3OpyM7eBajgp6nj SEtGhFliLEe4QiFiCGzRXmfAzSXD4nQq0y5ISz2BR+0QBREotaknWzDJwwyY5jdPWewY7j0T /+u8bQ51bJ0HJD+FpofINiyVRV2G5XRwNzud7zaeh/CYT1qOHm3Yx61V/U6eNvZzNzm6Kx0b Gm5w4dHkpXe6uVt6sPF3Kjbe2YGO5jgqRJNJ3An+YhpSVHDn1t05ppiu5OzZ5Ohjq/McPEI5 /V8czK5nA9qeRs+slMfWdEkd7vetPNXimkhpdefptmvPW+iN3mOZMgRQ+QEV0Is1pL3GF9JY fQM7CGYcMNDAhZo6OGzhCDNnRgzoQ94+lePMeLMpaxtswrCMGMvCkiv2mB8HNu08WOh2b1fW bHVw5qVyhs/O6G5u7nerqrg4RwcGG7k2cK3clY4QMIcCzQGFgjosyq0Mw0BYQ2YeZsm4aKhX ZJ6nod7ufFgwww+BP6wKioqB9P3x935e4j0lMnZWYcb0gkl2vorMDCEQ0IDtis63Ne9yvW+2 BH4Up/JWxji1Q4wSCUXB8VZgYQiGhAYxWdmDYvhhg0oPxZma8D4ADAgA/3AXjrAIHL2HD+p/ 3PyeJzEnZUc1TH4MO5XCTwY0qfW5N0hw2T+JNDqrZUaSiTCpuqGDckjQ8U/pY9qtk+aPrnwq 2e6T2hHyY2fIkWT52Wg4Y9H3b27PqlRi9r1b32lSryWXq7GN2ZuYhgv1ZMzJprLdjZskpGya DGnNsbUuK1EiTSFq7lcIKkKkmqJHIqRGzXk5uauQT3bKq/mQMggw+e1VVwPoBQWCYn/Eih10 8GH/aUNHA+hcc8v85WI3X/jK8LkP7Q9nrrewrD/cyYO/c7VIpL9muyX2GZCCtFs818Ckcnur SGfsmB+Pko89gJA3tUp/QabbP8k0ndlhz3cN26y0olZYjBGFAtgiNsPjdYNtvOrjhBkgcPco zP9/8P1Bhmd5Hhr5MI/54kMOfe+mq2mc90Y0lDnCHNdkb7a6JAGsbV+FF52qNmpRApgaFBup AHve/ksOeWpx+Rs/ioGwiUy+fvVMEhW2fZJQfFV8FVBPvkP2HuYfj8Pb7s0dvD/GTohtI18x o+Bp0WMoZ8XMrXtSLOhUUYIIFkK6aQyI0GZtwvfjszMck5drdzqnN8+B3/d64VmVsWvRo8DK 7o7mHfvK9uMOncNBOijUNUvYCBngBnpg2oQoBt+wYAk1Gg1pT6ujJkqG/zUNT8lG7w4EXp7d cU35PsrF89poIHaAh2P29NaOBcCfQzDAkQKcQ/cCLh0/uHskJgXS99bo29At5gDj7cBJlHzl oCt3FoBOzrVAfUQrw6jYExbBkFxSwrtC8RArqOdelF7IQTwIRO8p7gUolm5kQZ49g7h8CO+N KKLgUEyBM6/8DpsFE0dA1HlmipqSSXpcjpNOqZ5KABhFUGd6ihh1Rb4kJwxjkHHHzXjcIJoN SEE+QiOZSIYFUDhQM914qRSCxQSEhUKmesYQ/aR239Oy97h97Td5ZumlePl4SOiSoWelePjP DlwcgnMTUIiuY+KsIwGpDck8gA7iPhYwt+76D6P3Gly+hSzmp2qlA3hmHbmSextAB81kHVBU gEoPlaoRUPcRxNmniw9uqGbgXFxh1/KViNt8pXhch0h7ONb2FYdLJg7/R2qRSXw77JbzMhBW i2fFfsKRye6tIZ/GYH071HTsBIG9qlOo022dqaTuyw57uG7dZaUSssRgjCgWwRG2HsusG23n VxwgyQOH0UZn6ePmGGZ3kfPXyYR9WJDDn6PpqtpnPdGNJQ5whzXZG+2uiQBrG1fXRedqjZqU QKYGhQbqQB73v5LDnlqcfQ+RQp3lSQTd9P2sBvIrYVs+4ooBILqo9TMPTr0a2qhhHhr6dI6w ScCqdKzYIzbgyY8o+UBAbkMgOohSEw6yCAelevKMcpIvSQmO2J5UUc7BLNTNh7EdJKwc5F8F QBSmhRANPRmH3DJQPtpv1QiK4L8WagYSJEbhEZCKoHChAo2K0EjwJGzosRsqDSs/hyG6zDh3 1r6Wd3Db4X29vZputV58Dv/H1wrMrYtejR4GV3R3MO/eV7cYUV2EQJ0Uahql0AgZ4AZ6YNqE KAdf3DAEmo0GtKenDbvUm/2qGp8NG7w4EXwduuKb8nHWL5rTQQO0AEbPz/BdHAuBPvMwwJEC nEP4Ai4dP5h7pCYF0vjW6NvQLeYA4/ZgJMo+ktAVu4tAJ2daoD6iFeHUbAmLYMguKWFdoXiI FdRzr0ovZCCeBCJ3lPMFKJZuZEGePYO4fIjvjSii4FBMgTOv7jpsFE0dA1HlmipqSSXpcjpN OqZ5KABhFUGd6ihh1Rb5kJwxjkHHHzXjcIJo9JVv6XD6rOGlyNmHq9/g6103ziOTk6snq9jx 3/pr7/Dp2XvcPvabvLN00rx8vCR0SVCz0owwS+UQ5BOYmoRFcx8VYRgNSG5J5AB3EfCxhb93 uHufuNLl9ClnNTtVKBvDMO3Mk9jaAD8yyDqgqQCUH2WqEVDYUKe8qSD9qwu62v3qGGV13TjH AEnvKpqWbBGbpDJ2dMfhAQHxQyA4EKQmHWQQD0ryyjHKSLwITHbE76KO2wSzUzYc0dJKwc5F 8F3bBrYDgRDaoxRppqRHkUjcqIpN+oMN0FTEHCeFj8HUefnuUFg4ioTJgu0dZUkEAk9PTtZI gmatjPL1Zaa51I4n42rGW7udNRAjw2drwNpQ1B35hXA5EUxUTRrEuRHkUjoqIpNnIMNIKnIH VPCx+TqOWfJQWDiKhMmC8hwKkggEnly2skQTNWxnlyy01zqRyPK1Yy3cnSepQJcNnJ4GIKGo KyfknS7u4DnmJDMXD/IIooAHN5uAx6Y/WfputMNXk9zg5HvSJPFucz/JGEqJKVJKhQqpVKhV RJ+ljEkk7lGCoR/IhUiKsiSP2Iop/3sJTExRUP/2//TH8iVEmFENzExCMQmKx/8MRJVQxUYo VjCqIpRSpKpJWDdw0bFc1VSmNOGNlSqaMEY0rEwxVYVTdjSqjSQnCkNDZDGPuc2jRVJU0pGx UmnIxMVVJyN2BNlIbKcypiVulCcm7ArLaKq20VRwkmkiJySlSKpSopSlZSWW0sskqVJUqSRR RUUoUNbVbocFOSg0lcikpUpUMUjFSC7W5SVZK3dF1lLZx1WS16utGj/5UmKlUOe9ulY03Kid ApBXYUKuySKgh8xmbY+sgFgKHx5E3RJUI89W/qDZP/Q3IT8z9x6k0qIEP/ux9/O3EOn7O2Zm iJVDZjxCfilv5LbVVf4a922qq+3/FEQAAAAAAAAAAAAAAAAAAASABIAAAAAAAAGYAAAAAAAA AAAAAAAAAAAQAAAAAAAAAEgAAAAAAAAASAAAAAAAAAAAAPxfyVg847CH+p3w74UCB+cfaPSD oPAC84lH3gKfUdIobDMEV9JmKJmBZBdwX9wuEgUSoOCcBBFR0QFH+xVRHIqSTl7FqkNIcn/R iHYrydXDcSd6RGlSSQ3I6kRipiNyT/tCqP+BSYbBBw3Ru2K0HQ/kT/4ETxcibvMMQ73mRHU7 IjdAbpJNKc1PRUjBo3Nn9AT/c9ZGPUncOh3h7nNJP6G7hKkjqShCHBRCYgO9JE5u9yTSJO+f N/oCv8U0kmMJVQ6vJB1ViViscySYxjH+0/2lLHjb/QY0+ieaT+F3vjJ/LbbbKx6iI+wnNs9z Z5OE/sE0qoh/wJK2IOybjRT2p9jHtUqq+5J2RXI2VTD2uqNDEsT7m5VUlH/7MSYVUCqRCfZS Wqp+5SYVMUTFbq+9SVpgX5FKWYgYsLYS0MLItSFqFyxtVco1FGrbRFrXl+jT5BP/0UfFD/tP ox/eT4nmx97ZNj2tIdyE9HvRPUo83vU+xO4SOhXoJGEwRU4YiTmkpSpEj4tOqvYj/o+KlUxU qinysS2RMCyRlC2YVGULRpUmVC1NIaYapaFsFsxQyolpNBRlhbVDELAypItkRgNIyJrxWsbd VZcjWjanlV21y0tJLUktgw0JMVVVIYpu+QZiq5GBocBgshQluokRkVmBhBgA2KjRBOceQ7EJ /sZmZmC74PWFwkemtZmf7H0bpI4Dk/9H+l/6JJsNz2KqnwVHNU0onWxbiqVKNEokoUrGGJPa 1JqotkSqT3m58jcr8nqKKOB4A6B5Pa7JD63/eThPF3phJySUkR71eSSSMdXRJsdnM0bmweR5 nMcNhWCR4OSROxSSUobt3sJh+ImlSYYlCvzJJ1YlYYRjZ2Td1SShOYmh3JJjmpFYE5Dh6xub t0x0H0foDDxFOxuneP/8qq+1HVP2jA2UqUn2K6st0S1co8yvTTKb2FQ9DQYaDBKlVGnor9im 72sR1NGOqSo3URUjhiVzJzQ/Y2TqmyoKhsf/r0ZiEiRk+AxJoQxiXR5Fh3P+khDzNJawk6tM TLGFTLGHGW4ly3EY8VaVpCmzEe98j9J7kP/wfY+p9CY+9H5jHxd4d87892TNFZdZM1XkfByS pJJPiqf/d8D9qT3p4p/90gFUiSHVQpEnYxEk+9ivg4PkrsQ8HJOTzs2b2eN43yoi9ORF1eXt x7ry80M2fJJMSJ4kBUnIk8CpPsJOEQNiJ4iNH4H8pK2R2RVFUqpKbIk4Vsn1kYdFI/UwjCNr bCuEk5OqIKhJ7iHRsUw9bmSHNRI5vsJJ3pDkiOap4o4T829vMxRVVjDqTk7kHkjoaVIet6kE nwPF3EnsPaPI2OYV5JMK7Nnge5pFO8DFHQiObQac0hwqQY6oqNJpsw2RFEmklP2vueRp+THo 5NNNMYx7xI92zfRvJqbs3YyWUN1I0xJCdOOVAaVEbTKokBshkcdVcqply7qwgELqk0rsqpl1 WVSqDwY6UobqRpiSE6ccqA0qI2mVRIDajdVJVTLl3TAZKpNKWVUy6poFaGTFFYMmYmhitFEw xgxQ/4hhoaQUyjbKMTKMaAZUq0imaxA0MQVdqkkUyWNoOXSt69deSkp5rCCperyl0iDGMpAy yDlgSpIBLoC0rCFVQijRB0qoFSoDCyEpsjiQKEcSBRtvVJVAekrCqhUAsV3AdXC7oV5jyLAl XDLrLzJgHkUICgwqqLCHEe5WEj2He8AnrUjZSVUkHkrZSDsoJsqBSpAntFRDskqSTSVJs952 dhFfiqhwmh0fmSIe5IYpHu8pbDZMcPrNJ9zk0mkqdzeyWxyfvJ1TCTG44EUfBhEPuT+JP1NI 3JFCFBNhXzIpJ8kkTE8T5kAfIPER4mBJ4FJPRG4xPIoY8nDZse0cEeCSJ1CTd5/lbsmOThCf WdyTvKaSSvL4bjqpLpacdbSXSrXcdZGKxWKiVWKRilVikMq1DTsY/ubpPzP3sdH8J+xX6Xke j1J2cDkklUaVzckn8ylpamKr2KOQ/QwxH3qnRJEPtVBJJuO4YiknqRJJSI7DmUMEbJGxUSMJ StJomkmgxEVPBQdCVERJpFCcH5JyJSvYmK+sRNI7mySeSjYJNh7Cvi4bPAc0Tk3Spw6D/M06 tOx+lw0oK87bOqUNKeL2PAjuk/NbK+KSTd8ypzPQ/EJPUUUk4SSbFQxInApwYwqJJJPE6HsP ziew5knJ0eCnebPU07KiPJTwNx7RGiOh1K6pps4d6NJ6OjRIn53oJ6OrkbOTqJu8GIxCG6uj DZsgdCKo7kcIngkTqhDvVUOiSOjT2xC2yUlq0qqRzKPeNJNgm6USqEncg5HmJ1NniK5E81Ik 6kJUklSTojmHqClP41RMcW2pO5WHgYfnV96T2vxe/3zXOu7Ratva9Ma6r1mMarpd2y5J3apL u2XJclqVpVV3DqwaqTfIWzCyWWMZGZi5bdcd1Y7aN1Nma67XdDuktyMlllR2R1QHD4MScz1E bHRKhU+B5vYnUqRuSTuNOaIjEkGkm6T0YOGzhJXIrEYlsLZUKpIbJPYc0k+KacPADoN2xJOz wIk0iDoknmPcSDvN0NyR7G6ExHZSSc0hj87hCvBw0jvcjGzsncjZSpJ8E8Gj1IqeKvg8FPU6 iR0cJJuE3SU0r8zGI5HBGJSKImK9hiQ5mk/800gPN+L0dD9YHJ63+R6xiJ8FSVyPrVJOx9Z6 hUiScBs9x1cJCehK6ElO82ae0SNhHuJzbvUiH8zc0V0eaHdJ3VJbEj4VZSVU3R//lJE5KlPB QnNgRhUiMJCvRE70RQqRJzUkG6pIaKhJ9jT+UUn6FSejzfyq9aebdsmNBO5KKkSmjzTxSJug xyeYEUjo5PUBNEAaRUqexTCQdnJJOBXR2VIJ+ZmJjJBiR1QqHCHYe1o0fxsTqUpyJHZIVKmM RhUJufUqG76yMST/dZJLZHCByQ5IPI7IjdiJXJMN2mlV4jTUR/PBJNz7k6Kw9H4hK/B80dBw myETxEeCKST8yT6CoT8zo4QYx3GkjCAOyewSYqEbGGNkO5s8hzScxN1RHNzRJPAkTvPtbuEm 7zNzSmxu+tJ2Tvcni7nm6vAwwO8iTZgxJoqKUjxQ97+T9NttvQ7nN5DvJ0DTTDyabHgR3O53 MJjFViMtZZbYWMsyFGfNmrLbCyWFk1pSdypOzcN0NS4VhcKzEx5MTCV3uzGmkg6PW5b3eYsu G5A3UQnuYpUYEqPzoKYqTFJKTDExMRMfpVgVSKqooUqpSj/8SW2iqmGxNGEblMTv1jM0fNjE myokUbkihVBSUpMJgxJMMQYTDDBJo/SaRDYkK/c70NPgK+9BUQ3Eko5MQxIEPNgbPNGj1B9a YknqRwjkc3kaiWrUktWzBUkmVVnV21uG2grqVq/z028F5eq4qPxU+t7T63scKrQ3d6DVtqSS lJiGiT5tDEkepJybppJO9iSN3zYifB8W5Em6PFTxfcYkbnek5sT8trZVKlT1tkcjR+BHk8Sq PaPBEk0eSFUgqV3IqEKo5HrCyA+xUwLD0J97HND2pPsqS1DdE3fNTdRNg7hzVHIKcmJh5cOU kzKuSTFclBpKjRwoej8nZ0cE4Wr0EjkkkhVd7RUGlRoVp+LxbPMpHrEqCqIPqRKmk5JCYk3I nY6H0bMKcetVtS21VtS34ned7kEqTh6CtKjTsk9HDqmxs2fkRDkibHJ7kmJ7UQ4QSbG50JEo I/ENk3fFGEmKeZWiROZ3DSU4kG1ujHcbqTGwaSbp1cEUPgp4KmySebdp+ZPck0h2DvdjTGm6 etDsqRVVUiqH9yoxRP9LxQ/5kVPBnhPV4bt2+8UkSkZjCrRddszKISSiWYVZWiFFHk7zd7VT hbbLbbFWuZ62nJVaRhzaSoSsHN6k6GGyYNzdZpZisc3rQ82MOScHNzYd42T1IHc211tKqiRH vm8PAKu4L2jsDwg7wInY7sm6K+jyIjsqRJRH+wrDwGJuniE2cJCsDD5JInokwr1ni4SIno95 h1PtI5iMMVKo09qe5h3KiD0CRuioGOGmmwxsqSvWxH3JwxVUqqpVUKip3K2P0nuSc0k6JRJ3 SfZRVktFUrsh+ZT5KWtskpSpZfNdbhlJSuA5PYY0keRU+BXCd7vTSTST4KT+1+hiGwdgpU8X 0HV731h8kidzTveRuHvNmB1HceKp+KyIqvQ71OIoohNvk1xhiokCpGjDTdgQMXV0OfQTSM1Z WZYplsxuya0KZcxM2E1IxrMy1ops6nzMGwpKPFjoxI2cNOUklq2HQrhrIWw4e1EbOs2UVYpO Z1N2HRKcIwmCFUGxnuyouLVurXcSWLINLZhAQYFppHU5ttra4VlXdOFRoNE2Y6NnDdGzTGWs Yy1jE6EnYiScKHz32ZvvRSZPqrpJeS660kxfw5mYmKH1tGJo2SpSo5EnmIqoJ8k6PJGyHtMH 0VhVNMUqE0+ozVWpLYtIsVLFSesKikSV6083eqMYSN2zmmJU7mz4iMNhSPA2aV6zmjc9joqm Jo73JyiJ4KqyVzOz2O9HsG6HBTdpIj4u56DuTcnCYg2QOQ/gVXgYKno6qOye8fi4MGnQdEnI qe1s9TwbNHgqI2SkTsUqPNpySVVUnMxXo4SaYk4McytmmOiDokaGzc7JODs3E8H+xU9iokfz H6GOS9n4f9APkJDYH0BCjfH73T4CK/8h+hZVDgMJrMoNrtQk/eN4r0GzweC/AhnfW7ro0+jw 99iwhx8VHi50kvA3i0HoaDzP5hBYQRg9D4hiVoH/S8sscHiGJWgePP7kJFgjA7CChi3MzMEx KSkmI/zDGySmx4tCEDDexQ+hvp2KFt37B8HTY+Hg9gdH2DxDzA+rc2tRdNyyP/QdkssdwHWG e5NFFSVTDcjhoeI2Gx6NzdtczFuZzNk3NkNzhwaHv6VbwN1t4rN2VRipRDg0Iqqhrc+XDerK 93uYdVofSDpdWddYHVqoNTmUjkQgdkeMBX4BXkEs7wcwj2sP0vvSfUIqJ+T+Uieo/Mh9Z1fs VJP0JU/B1JHgknDk5klGyRHtbDT0GyIfxOb+gU+89az42+w5ojwJFDcjQ/UKOzdPcxjpIlsW UoqH6FiR+wLKFkn89tNKFCoeVTV4xW2WW2vNjYpdLrKrJtbPaUMKGkpiUpJ/QlGJ8nid54tJ s7O8pX8LMqrYfysJs+T+pa6ylWVpbMNyArdbKKpllsw0HJwadiPNjSifxv/CI97ucJxvVs3T vfxjmOhSHJ9iknBJFVVE4ICPJJwwOHimEjYRybuQiIcKSEwe75Wy21bZSpKSk0qGLKhjZlMh TxStB0TuSTfa2tKwsUsq1eAOAPgh9SYDQxEcJyaRNlV+04RpVSKkVNxzObvKkxChIAAIaZSy mSAklAIo2+Wr41Wr566rbfhvvH0BB/kB1DRA+khYHnGBcI4EhAqpXqvLy3X6/sQ8vK3tSvPQ kCXVeUpb/pK98r2vfLKWBJK22k03I/8UmETc2k35ZmTT/e4VwmnuCxKE2IbIp5IAlRSoCsgk nGdAGzp81FVJVV6QwJxkANqyQ1kPrIP6yzBZgH/cf9VuSSVJJJJTGIR+0D+or2hVH2hXe9yn ifyH1tGxtlsnRox/alR/S3Jh2/4v5NvYkln9aTm+SSf8fSSSVbtJtKv9JTDY5NjRbbVRXeuW 4rGz+c6tJ3OZ3v0Nk5+OZmTsQ6jYp7lMP2fy1bVU41D+e4hsIyGJSmYMaJNGKMwWhDUo0xQp OgMqJFuBpcRnKKLkJBAOgQeIII+IfjH/N+j/keQ9ow2OCfWTY/oVSqUpu+c+MwZAWPOUGZ2Q AaH3BoFdwUegU+U0hwNhj0fUh+95uY/tMeJ+JOaFSSVzdDcN02dH1O4dSkpK2JSMSfW07n9D Z/U6qqQryMkyxa4ejHN/Sm0pZH9T7x8Hk7N0ST1ujwTs5J70UkqOavJST+po3f1EnuCPb+C0 tWlYI9ycyqoU9Tkep5HVzHMck7ykpu3Cdf1W6dD4mOYkjhPFE82keiI3e07lU5ITwME2CxNW ypSpC0tFVWKYVieRGinmI2claSVJ5lUtWpVIV2YmMTJMssWrPgk9EnRORuYPE9GMSFeQ6u4V 1NiMbDdicj4vaR2J0ehyPF4nR0fB4tNMYxiqxjGMYqsY9DwdAro5u5/Q9h8XD+p1ZCfCLYpj zUUlKmMKYgqie8Ri+zUv1q3qr8l9P2/q7u7gASSBkssxD5pGk947N2m7MtslFkorEPUk9TxV Mf5nxPBHvV2rMxlDEFfNS8rrr5qqLYhQUWpaOR8RHBhPRCTk+Qn/9Uk0R8gfHbIslJSUpUku 66WldiMMDJluIXFq1atWurmTsVMSU9Y7zZoqoqVFVVS1LUqVIqT1O96no5JBXg7kAqPEm7A6 x/ZS21FqJ6JKk+pKE6+/5c5rWtSuHDuMTDHIlPrWrSqVCsQ2EV0VjcYR/batrEsiatlSUKHg k7yId6VElKoVCVKIUhRJUpJJRQUSoq2ytrFaLWVsqWVbLWW2WW1SUpRjZay20qy+uvI9ttW3 xTd6kOHg6NJI7PWRsaet7R2TCPYSSHvetwjDYUe9UNE5MMQFHVJuxPc70ebzPi5p3lFd9tjw QMRCfUdXRwkPJQk8FSOZUYlQ7jZ1I2Kg2lqraWVYqRZJLLZw9j0ckPE6iH+c0I+B4oqlUU+Y 6pNPk4eLok9QejcJ6Pc3K9ZD6Pe2etJJ9R1HxeA96dHCSdXkknQ5PgTQPg+Txbuwk3R7k5nM 6q8tLyZGZMS3z3X5l+dvmYMFsW/IkY07H/p7vM9+taNc36F0d9mUyv6BTAwINHcEOMAiJ6WR h6iDZFS2/4mGKD/BUjGDBI/wVKkpEaVGjH8jQk/Z+2222KYf3pVSilbqVR8hho/nYY2YlH/i qpRNxo2NJVT/UVMD/WrFLNWVdbUl/rl0tsspWUrXtJIqrGW1HMqHonM95h/7vyeD+1pNNKVU FeLcP/dNjCabI0/9XwYIoI6on/m3JzFRuD/YY/hHInc/mf639bwIf3uY3LMtkd6TGjm8Tuf8 k0Dm8VP7gaf4uhTZ2c2z++rVq1/MRRKVpRUeSaaVMakYsilaYYqMDvORKnemmnVJnFuj3MYl dzTPq2SZmJOB4J7zkPYTxJ1SeSUUonqTzSSfzODY4PFVYV3niNJG4D/ODDzKoR3MO3Lkkikb cMKqs+pJlBxtbOpw4GKeTd8D2O9zKpXJzVCvcHV6nok7PewmKD2keDwe1u9w5obIaTSnsbIe 5pG5UrGJDskmOTvHxHBKpTcO4qRGKTTGE5PFMVVVGysGNlVM1b4lTHJ/ofFpzSOaPkr3q8mO DdzdXxSPJMSdSTQjwO3na9B3KH+Cjs6tk/e0kxJ4vWetOvwttt7n0exyKJSeZ3qkYVHNHkk0 R4HejHm/R8Lejubvgd5zfWPeY3V3sYPBph6xoNkTOVtq1ycKqlWLatuwn0dXsW2/R9rqdjxF SHxT2IcnVOhjZ5tHFLs0m7vN0YrZux83JpwK0pXBucmLKs/911bRUJJGCNNjejSaaapKktZo MjrEkWkRMLjq0kWkYcLFpKytFkJsEIFTKIVhYbMILSVQswsCtISKDB1EoAxBSEAN83qphrc4 +LVPSznMqYc3Oec7xM4nsTsIe9psVFd3dmZkVo96KaHgN0Y7jEFNj2ihSObdPF3O90RzOQ6C bOz0eLnbbVqV1e3otlq3o9jzPh87d3N2SkdEpUlOjxd6lOjYrd4JJ5qPoHRuex2YPe8nQfNL J6ra0Nincoqh2IdUe5jhyTwDk7JXinsTkHQisQk5p3nq9VuJonRN07gbEmnU3R2eiOqQ7JyN yFJyfUV9Dow6DwkttRVGEfA2cydR3TsqrKqi2S2e1Nic3Mkle0iaPF1RHUckQ/hOZ4PAdkkj snyOqUhRp2VXJUdWlY5m58nHW2pNivIT2uFPU2V7nVg9Qk5Hs8ttttK6qg7JfmbbSbdYhINC CkCA2U7BzRhK0qSPgmMJoqbqmxoTEbKo2YSbD3vRhslcI3ThsHJ5vF6xpj3Dm8Uj1Kg4HI8F PMqkVPA6GDGzo0bmjgnuc9LWjG40KoiojdMSfRPFT7Xgbve5OT6k81bE2O5u+BKJpPWU8nua Gydk7PYeLqkm5JIbpVI5E4HRsGPR5sUq22VOr4vUnKy2ck4ScyorEmGytHVTEdQ82mxUVbUp UVbSrVqtz2DYZ6JOh63VP0B9A7n/I+Bv0slpHJKPWbmJKUbkewVK3GicMVsxIwxMSPcrdUkf W4MG6pw8WHCp2J2cEfcR0Sc0U0jFRiwnJelxczJmZMkqFZgtllFspWKKVw5DSaQ0oxo6mm6p KqH/I3Pqe94jckQ2I2d7CP+KIVD1inUD/c+SnokI8zrwuPC5NdyzFGrWeLNaq43uWzW6zFGr Wbs1dbsq/0QQqQ9bdCvnq69217mLZZZoTGWqxNsTBSP/RiMJwA3aaCeaUOF+NunraSOSjorS psp/UqNlCPBU5D1KjER7VBPkpJNHBWEVJTcpK9p9jEn0T6gpgpzeJRKpFPufYA3ejZ1JI4Uk 9qt26K+Dc9apyNn5Gz3Gk07xDqn+t3o5NKmKkklVhWJEwKCqw/8+jyfwHodiiqilJSkpow9E rSqnsKjYbsYN2FUmmjTGEbqmyKr5pibFSlJobqqt0Vj+RMsr7/uZNStaYqm2MM3R0KqEUlLf 1f6T9uhAXrxbUe3vZvQgL1u2bVJDgWEFYKQWK3JkBkMCwMBgaENyc2ycmJhsilG9gticpmG1 iZYmprGJTspNAqN1VTRRipjTGn/FWJJatEpVKlOjJDnbTSpH/JNsnXlc1ZmsykcyUicFKfE9 T1KUj1qT4H/k+tOaPo+5SoxN3o/BMRihSqrhUmIlSSE+Co+1UhP86uBKc0gR7w/M+58Su8+1 6h+SsaYGHedz0JI2G6hWNDQ/M9bHVVPvOGzm3eacjhWK2MfmbNnNyYnZoHRR/8ORzdyT2ups 4eBSJs+aSuSJ2Oan5OfFtSThUjxYjE0lQYqVX7lSCf7Dc3DxMcI+KFRVTgOyiPBXY2T8B+oU UKJ4ND1OZ7WieY9gnv3PFUOH7G7kYPFpEk9zbxWp7VetpJiSkqq2UYqVU2MYGyvUkHoTGJOR 9rifKlv2qH0VKqTSpKqRpQ+io0pDZXwMc39zvSE6okfxqlEUUkpUKR7lSaSqPM6vBPJXcjzJ yB8z4Md+J82jg+tUfgr2pJ6kcxwUlUI6lSHVSEpUmmMP/VKQPrd6j3D3lfilSlO5XNjkketp MRNIadXqbGIaSR8lTvKVSVVUT1KGJ8HJQkng6NleSvEklKJFftq4jCv61AN2g9rxV+d0O43b qkOyo7IhKNhpUN0mJ7jveDh9z7j0Jjccgkp6k/I8mngdDzHYROaoEqdxTEn3O4cPikqPJ0Yw qVMQmMMYpivc07lbMMJW6H2n1ieoklSVWyYmIToUmjTFVJGKMaMI7HmVKeDCMSpKhSqqVE+R 5ECf+yQe1E+B4E/MoxT0TwGPIetPY+am7cPWlIKqolVJKlKlRKUHwk/wqWxatRJHIeaiHxdW x6OqTgOrZT2q+DTcShsxE/FHJg2WDokMFy3dyPeY3dW7k3bO94O8NnY4SRO9Icw6uzvfYmyE 3dzhyJs3YUqsGmB0nK2bjYeAo2USj7zd3j3HvHZ+42CdzyeKDvetCDvSOD9SnqeBKklVPyVg dSmDZyU6ur9KpJWBhKBOB6x709SsdTDQ2Rp/chWNzD+dp5OD7h9yfzEpRThNPBNicnA2GzTY Odlsh8yfk/lHoUf5KfB+06p0Sdwqp3B/KqlVRsH4qJ+kfkxEikqj0MSSeTyJzHMbAn6FkOSK TZsw9ij4E3BhpiTH2g7OwmjZJX2nuYfnKNjhVY/U7NK0+p+Dz86tkklVII4KkN3Cv53if/ki f3IWyWw2BQ/WFUMetrJLZHgQ9TEfeo7HsJ3NKSo9aTAwoqPEKOrYfzMGJFUYwYJ1TZQrHM9p opskaGz7G7ofuYOxyZJbZiY5FHRVcMbeyrYVgYpHUpHJhBO5YJtYJfvKPA+L3Pvq0mhGiobK iSlNiocgw+hu0IbuaCcgxpE5K/Qlc1DRps3tq2/ExwqkxKkVG+lK63KpWWYKorFFVlqTuFMq TBYiPAcFJiU2VCCEAw4Q8EGFkCDJUEiEkFI4KQZARBFHOzGxJQLLMpNtpttpLerVq1GYgElJ ZgAJJVZVKltJIzGAktqSQACSkswAElJZgAJLaWVdzdvW3It7eyyzMzKvA3MSE2k4UdhXDMjS jBWmbMOhjoxKmhOpPteRyOGDCoPuStKaeYwGBpzMacHik6GHuMQ3Y9aacKk2cJKPQnI2Rosi l2MMMPcjk96qpho3TFVYqqscjmcjDc3Th0VUw0cjFVYqqscinIdgmJIYlJu5crajRGk0lSaS RFeW3tfNJSpSqqRu0eSqqv52H7U/pV8Ukf7lR7iviUT73vYxiNO9swqVKVTRDTRVGmNCEkxF NHex8idjZs+CVUopJUnQk9iTqdSmK6NGKxU6qYrmbGDGm6NlJhEiUhUpPc6vqKeZ6JJiSqHr VKYjCqbBydkg0PaUe006gYRgkwVzOam7Tkjomk/+wd6DHzDZJPFUnDk07GDFTzYwTG4qsYqK YqQxMtsmJClSUrFJiRUpKKRmW1HqN1MdjoeCmGEqd+jcdxIQ3bn3qnBwbKsqyIqfBMBhTRjF BVIqSVVVKVKrFY2fN+Z1PmSuA+8Nx2cz5q9qKfF2dDubMboGHRTZSbp3MOqu5O4+p4TljJm6 TZKqVU8GzTFGylXuWlqxulGyjqlaep6J9qu5uY0VwmNO5JQ5NzokUnMmyT1HrbuZ1JifJJJF RRyYwkKqVQntE0mJIaUKqSCklSVWJiMKFVJJhSWrVKHerSmKmMMNNMFTTJlujBDAU2bGFUbK O5H2j5JSlKMYVTRsUe07DqeKTYeDyQqPNiJIpCoV6GGhowwMSoilSUxMGKJR/mEMBj2piGyV JsbKrGiVOCIdni6laeV+laqy1Yhq6uqstWIZbhX3NJ825GSJssLKqrgG4NnIQwbor7SkjdU0 0n0RzNkOErdWK4aclMaTEkmy4oxommObGgqbGmMYVGzZhpIqq2ShpMaNJDTSbqwmjDZjG6im GjRgrZhikCVK2U0aYUxs0QSaVWMQVhVRs2bJpTZRhjErSSNJommDGGKmMaSMSTCVVKrZiVSY qkMYTDZhilVsc3N7m5ykhutMAVjYlGtepmYrlV03TEphyy3H6Wws3ctTNStXUrSKSMu2Zkwr sbuE5JXDY4THDCtzGk6GEdXNHAoko91trGldzEEnIoBo95Wjpz7XLVy1mZdtZV1a1h0YqoYl QaK0T2mJbJbMSg2QmG6e9HDvdUcG5sltttuJjGMYxs4Twbo3RTFdTk6PN0buTm71GNjZJiKr zTkpg3JuQ5jc/ewM0cJ7jrKsnvOZseRo0U9FG4bm5pWm5pobEKpGCPaeJ9hSKjs7PY4TSH31 EglQokk6I5WW+1QiiQqRGitBUkNBIlJ0a+wnejmVDYrZ3vXVnt72wrso9pVgKsVVsLZFpLUS UsRVkkCpVFJU4Pccx6utuHYfEwf/CIlUJKSVEUFFJKiQqkSSqQlf+5+dg5JJ+TBVEk+o6omK knQlMUSu4eIbE0/crZScK8nobMNMDkexTmQ9ZKm4VJUexRDhI/B67b7Vl+bVLXq9r7VdWrav wf9gAAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAPVvkq997V9Evmsq/Svcf0FO5JFSbH c+h0VNzmicFJSirIqzgRPJQcDYh4IkrdjFU/O97UlWGkVUKo2YyrDFX2W4VSfcUcxIlSNjxJ jjksqxZSyw073tdknuDwCqEilElVJFoloSRhKkSHN7QwaTt5TJmTIczoVMVswnRX2jd5vwKr ZiYVVYMBisKkoxUTGKMCoxRG72DuV0VKn1vFsmlTdzJpJXQYp5j1HNRknK2JscHeT7z871Wd q9LV/HffyzN94jnmW59MbWc0YkLnV8103vbSJv/d32VZxOZ8/A/HT67OgpiaKK22k/Hjte0j fbxnFWeE5njxnXXhlUMTVAbjK0Z2zMwzP0n3FfvLOig7lmghVHYpK/SYcJOymySTSdnc02eC Y8VQx0+b2F0vXqdg0ei3syhb2U1Nho3CysyCRDTArRih3Gm7Ds04SOypDkVTgd5zEhg0jOeZ mdE2eLqbPdQtQ5HJ4JzNKOZs03Irg3MaNOGPJw6OR1bsHMOB1O5N2GHeqSdElRO4TAwNkqSv R2Q4bAmxUSHZSQYqpVVHoqHRNMSjvY6KQrTBOhQSdHiaU5uDd3mnZzcEqVThXVpp4N51trTv cOhpybne5mzo0myYnDFI5P0NNg4et1NP1OQdnJsKo8He7zR4KGz2MKMf9HI03Thw9ank7OrT s05NK5m6NJXVjqrcbsYabpow7IbKmzZyVup4q8DZMGnqYpSp2YjkpTuOjTZTs0bNPUrm4dzD hMdzk7Og5uhydEnVwpyTHNWzGmjd2KbOqnRzVs3VWDxc2NODmpyVx1txpjq6OHCu5VdHc7mG yoqV3lDGg2aOpXRu7jYnNydXJO44c3Y2OFThU6JXYTm5ObsPBpw7j1KhiexXLtbw7PJ3NO43 YqbsOQ8ynJ5MckocCUpIro5tFSvJs08Xk5bOyp4q5qjmrm6sc3Uxs6NmPFsxTzV0U4OHZh3H R1dFI2ad7Ds6N3RiO92Y6HcdDo02dUppVeSuqneTGHDyY2bBsx1VTd4ng5I6NGzyTZjo2NOG nM6O5u6uFGHc9Z0TZsxzTo2O9p3mmyJWnY9Ho8j0c3kh3J4OZUqkpVU5MBu8XVOFV5B4Ozuc 27ueLo0quibqjwPFXo8mOTvcIT0PI6K9pydUScHo0aMMUYpXC5bsTHo0xU0xhTGnRw2bJW4r okcBiEQEIRrUVLvKkpgI+RkipXAkpgItlrHlCkcK2kklgYYYV5CIHW/Q3JCMpM25CPQMrQdc mi7oirMllyaDNGtUYqvU0EC++r1lZmZlhWwgF78+1d7u8wMb2V7tmzDgHY4bKsOhBsRQiux2 aeToMY2dx0dWzdHCnRXRVdXVXeQwqgKqsAGUdBWHgsQdEPFzxy78IazPfrM0i7GaLEQ8HtIb PY0JaDsepXqMry+EkCX268+ZITCGBEAIUKFDAAAAACSSSSSSSRN8zqzOrNS2dR6HmAmKE+xs Js+x6nYcBCL9wJBw9wzhu5p5769nCloYI5Dy0r5WhmIlWuurj31Xs6XQylsYI7Q7bV9VoZiJ VreLJWja6lMinoQ4ehZ5FmykAd0kqaNOpSnDZ6I0Q2SqTQj61dWkk5kPk5InCTkOZzOQ7jmi PJNjZjEy24UrFmZmZRoomJMaaKrmMHNGibkOypG5UeJ3OTwOR4KnYnIiadzZ2RXc5sN9yInc qaK3UDuJUJ/WqsaaRJK0xjsk2MeavFRzPJyGiUYqT3IPtSNPzpiTvJSVFJu+iRoqQ5qhPine eKd5OEKk8BMTc5uacCpHDH89XYYV3sbKkmlRDSpWmDcTdTEKqIU/4FNxwcNNxR2SB3JPTutu /dX17Z5iwm+s3re7gKgrDsM9p2r6vm7dGjsap4609Zo0M1TyRW8kburZyOSkk45mzZsVw3Y4 e9OzwbtnJjs5MOyIrGnow4c1dXIBNmx2d7o3QJNzZB3JzMTdscK5iubTmkmmx73waeLvc3cr oqdlcNmOzq2dzk5seB3gNncwx4nDDu5W1s5I8Hc0jhU4cNJ1bjsNH2k0cjk80j2nc3Rydyp4 OEnDSIngOikYqRXe9Bh3vE8iRBpPgr4I3GxIB8EbOQq0qk6qnRKqqh5jYmhgdmyHvRUkc26Q iTDhMKeboj6lVUPvWMtqO/VuDTTH8SpHrQ05juR7FSOqoj3KRVaaYqgiH9R8TnbaqetzR0PF VHwH2Eh+dJg80m55j9jDSVVaCp96pPyaVWlVoxjDFRStMYJUlVUjq7xT8zFepTFPBskPmet6 3FX6u+M2m+Ux2rptUtyihjqSYmUty24lVD4Iieo+jvdDslaQ+psdVKpOEkjT6NjZWhiSoS99 XoACXxt6uvv3qrpLyta/aKHMVOubb36qqYfYaTlNgbQugUOk7UZKeYxi22VXq219KrYtS99b ZTsaTCpVEczFYg+9MYm5ipEVpyJyKTZO8Y8lGyPBiYGKkPWTGNJU5OzE0qLVqUkqWVZbbPFV faDhXJTZhUdz1OaeTqPyD3EJDE5J6JRUqngMPJs5tOZHkoVR1fFT3tmGPW06OGzc3afYxs2S cNykaVEIYVqy1i1olJNlOjFadCep6zBUVK0T7BieonsJudE5qiPWoTq2eT8SH3vB3uiPe6g0 02MSVEY+b5k2TxbodnE4dr69Y1dfR6x04t7NR8XBNubHk83vc3ZyVRyaVJs4aOg0mmJu5mmm 7GJGJybq6mnJjhyORIk5AqSTqbI0qwEaIQOGghZsohOkvlNmCQirW26N0rR0bN3oeRXJG7mq T+tUk7lQ5uzCeDZJs6uZP8W5jvdlTdwjmqSTwUok/4KFKRIhjT2pGE/BD4CfgqqSVVVJJKqI fFIPch61NVao2VVTDZKRSYfNiaSOQnqDveB3qwNneUxPJE2E+JsxDdG6GP0Lzvv/X/B9G3Dj OOOOHtfMWxg/rDQbPBDz8ithCQqcSSVCSSsiq06FfB3MVXVwrCjoHVw5MdGGjZZUGcPBR0cN GBoIIqCPBwsQYVK6Gni2eTkdnJs5EKQ2Tq2dXYYMR/nEV6nqZvrrRZc6weGO72dCNDPM9gZy bK7hDxRSN0wkdxNGCRifgVKU/VhaYp7XsVU9pUqvXyWkFVO9VYwjGOzTGmQmSrKlvsNRURar qsq2lSSSiT0H2pw8jRye8x5tHQ6PziVormc8WqiqKlKSnCjH68f1NmK0000f9qsThjEbtGmh QqSqJxImt8kpKuvKW3lTyxsFvLESvyeLGxTZJGCowqpFJMTESQ+bRsn4COb3Af4cz660fak+ R0JI6nNwcnZuUqDSISeioej4HiaSQ5n0U73kGyPyej2q7m6ThpJDxVOTR5qnxFKxwUhUUp8g piSv5X8DQ+2ljhUxisTc8h+k2QaDklVIqqqIpDFSoc4Wy+DDSO5R2GyaKFK/wShMSo/SxglL YtstlgorcfrfJLpdJS6nCXW6SUukvvxo8P0W/vaJSmw2abNkxXN9B+h6yicxxnwgr7w/0PtO QBEO0RLiCrRCoE3UrTEiCfe0+5ZCSaQlI+SN1EiSlNMKwqRJQp9r2NhpJJWmz/I0mw0wYpUp WMbKaKxoxJs2YqphUKpipwphoqtMKSlaCpiYR/nac7Fs6uZiilSQr+dFP/s0Q/WRoYbclsWy 1MD8iVIdyoqkjCoH4jhpXvSfeVVROFUoxBMVifgBmlqafwvqYaI02aRw73A/NS04bvQSJP60 rEHIR83UYmmOpDRJPU9acoJJUifB+c9b2H5brUw6u8o0HRHROpJP7Uf2lQ6vJffS2T6KObok h5ofAUc0f6GMFkqMYwX8goUKHeneqYnyPzkkYlHknvT3Ngfxv0PzrplW1W0zWmVbVamLbpuq T5sMNw5K3bP0KLKsxNNGPsTEY0aTHNX9Y4MbqpX2jk0aUnCsOoYp6nI0iOyjsSAUObkDkaTS jdWyuwYft3zMyv+7C1NOTYDdJEbGknMpGHIqcVaRs4YlbKxEwU0VHNJXJDDOKtmKhVJuo4tu ypuhUYSn+LdrViqWrVm40MJq89Zq61n3sTm0oxTKteYT8560TEg3G5TcFE6KVUiYrZI2aY07 pI/0mHsOpN2j9LmnNSjSORpIw9RXVT2qnB9jG5RwrYUTB7UHvSQ/neR96bOz6nonQqKHRyRs 8iXm9StRI9EbnNNjCbCCqkQ+tKbKcqkKsE0oklVE3VyUOFNraRMstSJhhg2UpThoxSsew0JH CP51SclTEjj22zZusq9djmjo5pwpoYV3Nk4bmnckqfraIj6H1PI9jGJisltsttlpdLhQXuuk vrla+1SSXkrlVWK7EjuKfko71CeJVYphihGFJJCqUqY/j5Wzq3G6qkOSjFEnzbuSo+CHmwru VWMO5UMJUoFNBTEiqkSqRJhRivi4MesetE6u5GHcpok7lU02ROEqvcqtGkQ4SJEmjZ60SVO9 OyxVk/JlWrVwkU4fYkcEChw5vikjB4uAnN7drS21PkruPFBJOiHgVEYgxTC7WkELSpKlLMit ooRlIjRhbJWlS2VLREYySZYtVEn/eO9Ij6HIdkPU4OboiRP4vpbhImOx+lJpNORRTSG7TCNi RKxVIoVoqlVWG5swmnkqtjSmNNExDTEJExpsJDdGxIqKKinckFdjdKHAjox5HuMR8Tdiq9xR zSV3sSRMOyJSPuTsJVSKoUKkKxEeKbvieCdVVhicv5KtkKqG5hhGKSRyNMQxRGKRVSEqoKpJ VTSipJPYT7G5of4lSI7lDhDYwaPUNhB3qqlIqiSvF2cA0RpTk3KY7MY0rSlaTSqo0qsYxpVU TcTGGxSEqSaczdOytE2A/wVppwk5KKmkrCqkUrGBhKqVUTFTGMMSqlSopockkczB0TkrHJie GjThJOSpCqxoNIkqDkTR6K07Dm+45vtV5yZMXEksxckiWgv8obGOaHQParY8HNie0+8OR/9K hzfocDq6Ow0U4U2aK8UfE2JoUVRNjFKpgpjBgbn/erzfAnkewY0KKKJSRKRKQ+5pu7qi0eLk 9HcPEx4qinQx4sH1uwdyEqO8YKFBRO59HvdUxWKUn7ydEkoKNne9BO98GB/EPgrTo00xIMUj CoV8VTmp4mznvbs0kKx0dEeT8HDHvSTs5Pyf0u9E5pEdFChUiqmKId4sje2kjhu0mKMJO95h 6dyOaTGJpu3fobvtPyMT4vRKnkniqf5k7MNB2Uno5AQ/vOUPCRhEB1kFh8Z4yxsgK4CAqf1K kkxREpSKopRVSSqEmlFVilKkMVCMNilMI5EOSTcPzB/GdEGBrLaQ2SSVBwkwSJO5ykiSeApp E7jTSlesPrUPISKk3R5Po6Kximxiv1FJiKIJKldxUickPgk+xuJ9b9aqdicJKBRJKqNMYhGJ KfU2fRNBpFI2SflatjEilVEf3lP60NE+15ursSfmToRMInop5ofkr0PuiGLFUkqfiU5FR6FK rorFNwoxVUqkKpK3VXMrzHrVJMeKva8U3P7XeqnxJOykkn5wkTE6Hrc2ENPA6JSYwaSd6kiE 7lDEp5JWFJUrvViE9ihhD1qjqoDRMKkNwnNPxVIfQdlMYdivJ3VXO3Zz9P5lrdwr8yPe+pp9 bR6ObZ8XN2E2bGlaY9TdX0btlep0cObs3VydXN0fWePJ7nePM8XJsbsdzo5NjyeL87q4VHi6 O92eTZTuOanZU5K+b4Ie1Kh7XxI0kfA0/JoxuNGMGkYnxU8if7lEYJ1e8nYPa6uap0R/qf6X RumyTFI5OFaTRT9A2MP5jCYxWwqQ0VCOBQolT1MYVSCqiVKiUoVU5tiYSI3bn534Nj2qbEit 3qYxXJU9Y0YUp8hEqGKcPcT2D2CI/7A4OEj+J/Q6tNiuZJH1KkkVUg8CkkMVIr3MQPtRH3J4 n3K+1HNSlCqM/m1rWtQqOSSQYOOSSUIpAhAhETkkjP7yDGW47FI4QolUhVSBFUgRCENVZhO5 iaQ8X3HCv+j9SYivmrzToTwCnQJ1hNAPfzk36qqp4TA2WDAgfzMirytKy2kssrZJSpaSy1kq SpZZS0tqWyD2va3KxraS2TzGwO5R/1oVpJ2VVttVQiqTD8D8Ue86p7DufWV0NgrY+KfqNz/J N0bvm2KYFaNI+1sYTZUc1QxU5MYbGNzQnAmzci21baN0xJoVsmymEbbW/oaSMUk8UacGg7yF bESeodHJukPmrgd4cnrehyfWO88FTRhijm5GzxRMK0VGK9FYc3xYkNk96p3NIYqfB8jWmgn1 nZHVUPEkolUh+1TvbMQ2IYqMKSkwwh4PkpsYxuY+Cn6Eo2U0MFcijYpGibI+TEY6nLphmVWO 97mng/8DDq4YqpzY+t0bK0nN62JGV7HUwYqu9jFNJjhpOSm7ZTQaVFVu4TGmjEdyQaSGxWA6 NJs3KK5uGzTGySSW2LSpipupI0aqS2LUluZbu8W7ZE3bqqpOrTDpksLmQMlhcwHgwk8jo0bm yUjvPA2P3mk0MTE3cIP2HM6DqV9yiqjdwlYwmKOrQ2Ixomyu9pJK+9iRMVV/TUgknzJCaMTd zY+obMD3q2blYHglSOpWw81cjxFE4TxPtOHT191WWZcqyy5mZlVX0T7CVXCe1p8CpxS9V7VK QfG45zvK91LzwhDGZb9azLdFVjLbjhJoc2HwQJ1YOhRs0RjCodDSuDHRsMciGHNTTGzTg5GI 9zgxpTEwx7mNNDEpppiqaVWKpjmo0aSsKVFKpiKVNGijDTSYwwxG5u06FKb726TETqyatqYc YtaVKpuLbZ0dGhsppWVsZjCsckwrJIJJlshphITDTKwm9bNNq1E2rZY32txJClNx3CGmgKk5 O9Op9EIR1epTqruad45nRp/crQkfdWNwwkmNzwMT2vohs+Q2OTqVyHNiVIqoqpisUbFUxJEk +jFVSUpVV9bGNP7lbps3bsKeZPkTmlDT6D5pPYSk5EbObGPm6HX2S2YiqkkqqqShUKVVUVAo VJVVPeqd6ViqUrTB8CpB6leSvVSq6spIyZqlkqSikVUlbMQxxmMzCDLbAwrShiTYhiIphzTz f2qVTzJ8Q5OGKxMK5Pwc26UNmDojHkjb9i1Uw83k0eabJisYrGKq724xlXRWat+3MtyUkVZV p0HvdwmIpOzseamKrZimwrBR8GzDmmHkYVIk/8FSqnQqRI6Pieo8TkVJRSUpKh+J7GNKHVHQ idGnvcmyGnorwHNH1ElPkp7G72CaYNlTc+I5CUGm7B3CoT1vgUmn705Or7wdG6vi0SeD6B+x FRSKKhRSipJpud5XY9bg6jY0r4vUkUlSeorHwuKy4pUkopFRVKo8FMKxX7FMVpSVSMVhExUq VVEJgepWIj/uFEpTRVKHvJXKrSRVUqVzdDmqdpq2mMejE/5K/of1bW1XoOH+Bw0VNNmJoVjo xP+x9B8gcjcw3MST3HxeBsuSLasi222WqkNCpjCaT5Ct3JTHuFJPoGCqMBgrthAV1CEAaCCo 5HJJHsNNO4SfoYPgT9J7wj6JU4R1c3JJBsqJUeDsPgCOqpIeIqJRThETh8n3P7245khDcfoP JJPqBOh95PFPFSvI/9CKOZh/zUaed+NZc9otFj1GmPzqdm7ufqcN0qQ+jGytKYY5sNmzZpUx SsIrFMVPV6fDM9NWfEmzg2RsKVO5u03ZNlqofRDBglVVRHMrZXJsOGGHix0aTFYwxhTwYdWy cke8//5N3Duci8LVtsjmtWqVSbOc2Hs216mmpvO3DNuHnl22k01N524ZTNGzdjKvnpUrq27M CmBvLKrpLKVSllSpUhUrZSRFJUkkqKSRiSRuQJyblV4uarluXMzMYxw5GQghNJtttjGNGMn8 7stl2zAKhslEKoVRwoxRKgoqJXw1iUspbEpt8S5y76L6Lbm6JsgjsTk6IOEmySGlSRFK2RMQ wIdlEnIogoio0qSSI9z3HJKnNTyfrDEk8B3ObSuqQY2JXbQ5vJj1sG7GjvbsB5Jwwr/NLLLM UqeLG7m2YWrZatlUVllsWy2OBCn2puczSEnJWknCkV+pUfmc2Js3MTThTEqKKK9A5pDwaH8T c9jd/YeD2oidEbKqN2D0KlKlU6Idz3ubd736xXrB+dzIPipuK/MTydn0UWi0KpXZ7GjSRpPE aZGrZEfUDcPY6OZ6Oj5sT8j0GEU4K5J2Yw7mx0SU8EVPWiTmA/YfBs4HcK/Ott5XwqegNvuZ pmSU9yOt94aI1S06KkaU0bN25Rit03GxhuUKobIqJJiY9ftq3+o3pXq8ry8asopsasopsmTy 9vDRRoNFGvv16tV5UsvlRVEGOtFo6KchGyQbtFaIUYmhjLJbJSkVJIrR4NyR5qnmG6bmjxZ9 dtFbPc0OqvUnmx0etIj8Wh3H1nV/g5z2W1OFaUYUxWlNI5pXsR8xSP8nYpulVFI+RpTQ0Kw9 DQ+9WmiV7EYw9hNjklJHkcIqVsldjuR7kxJ3JUVTSYGKJ/a+LQ0lib27tMY8mzdTogniYkno 9ozLbbaqaB3NGw+1wPaqcKlU9HtGg6H5mP0CNg708E7k2HwRMcJD+NEqRGOgrAqfi6FewGO/ c8Novnu33RRMkUSiiyUSgHGVQKXFEoolQCYtTVSXTSDSbJg2qLSbI0IYH/yMJJNlJDYm5ThT hUk0Ypu/lY04GlaaClVs0aaaY/oY00ipRiKipXCVSmm6bKpjGbIQqFGGENDCEMEAyGyGitIx VbJU0rTRpw2abGybmBw2Y3aQ0GMaFVVDFaVGNMKqVuTgxuTZp/vbOStm6jg5KNIwppPzt2kx zNhwRuYbhzOTY2Kkq22lFKlKmzT6Gzo5IMbowVN1VJpMVWNNlDHCTduxKdhPrVsqE2DsfaxF Pc5qaK5sVOT2MFV423ZNNKTRK2PMmh7FRwpOFTFTYfg0Ing3Hk7AAQRXQWVgECrHwyDRWNjb qrZekmVNsxmYhemZleDgpIwxwKIVQeRKYknNojZH8BQ9qVWzd5lU5ImMNzyV4u8m7vVK8Gga OltroVMFY5DDYhsSEN1NmBW0b2LWENKiGJNKbFSSV1GzSDZUTZU0ooRSgVhDcxoeBpUlKKMG zGBglREhRubiJoFEiaaKyX35W1q3SSqSyVllJKysut1rpJW0qUksqFSJ1V3ISqCRKApgP6Ch 3IBG7mOIiZb8Dc3P0DCfY9jE+1ifi0rGlT8VYrYkwryfUTk8GE2Dh3EJ3pEnqSPFkasWxUSi ilJUVKVBKiKilQtK1KWUkrSklJUsspLZSlqZUsrSpSSW2pSqUFUVCvRWIUqIlSoqVWJGCtKw 0K6pzV+lsp5Gk/Oge596dDY5IfWUiSqmjqwmymlRHxNEwSqoNkkYTED3MDFVujq7m7yDwUci NiMSIqpwV6rbUfcJ6CaI3JsnDmbDqFTzSkrkrBP5FB7FOhVHN2TTwBTufrJ2JP0vZbbbbbbb aKAKCEA+xfNb3Sv7t9i8rrCeRXUdhPRCk71JUxiYqqkKPapUPVq2TRKnkkYV4iCTZppE2RK2 YObmbITh/GpGD8mEYSSqlMcmKYlY0RVSlSSqiVKClSqQUwphVSSSWktaXwsutLZK15enLmZk zMmaEkfrNk0bt2PrbIxTQxEgYkUkVESnCa4bbF1pmi2astSYhsdWgcmnwUbKkjFRGE2cCsJT fYkkwlNEwRNJSabMSNKDwKGxK7Gx8Uxw3SSJue5wd6pOhX2PafWfa/Fo+iU2JRPYqeKiMVVP aqRMVIf1PRiOap3OgwVT/uMYNkpU0xBpyMTGGB+Kow3VhP7WOrTds3DSkk725oxpjHRUk9Si aRTo3bKYKQcJKkm5uaf3n7BE/nUaczGFEoqRKSVIHUdU0R8/mtWrUR3KjFVUGKhhUSqSMrFW 5FSVlr9u7heXXX7leVuMYngRuh80kT5EPre57UjZQdLbPBpDdUr5j9TTEkpUmKe5unJJHN/I gHcfaRNxyekKSpCTk9hR0HMNnZJ2QST8z87wfUrd4v5lTxQTufId4Jh5pJVU7yvm0wUk96sV Ir5KbJDZwKqq+tWiO5ySSTdJJSkctWLRIr8VDCqK4MI+LQxBVFUKpK0wxpiJgaVGJKlDhH0M J8kH2KhPU0knNSROaJzTq/aox1V4qwV0UisVKeLTdB9aKKlFSkUfMkBsVWzuVFFUqcE0DsSJ ySTkURzPI+idXs+xPokJN3U5OBwbmyk2SHueLknJ9SbN0SsYhsKhzeI+jqY4HROZJs0J8Flp bNyhUR4IfekmNlVu+ZgO42Yf3N0TTSTFFKxVVXf+FuJpSqpVVSVXBXCo0qVTCjhVJpye8VMV K0QaSncn8T+5yB+KX5212q4xO9Y0qaYac3im56SK7jZzSuhsnIUOQ2epDuUlRJ97d3Adyoqk 4TdzHxEoqGzd7HRXtQ5JY/lGN3Rjkn5K5cl64vCBUj7FSTZSqKqGK0kJVKoKqtDGFQ0xzCox okhzaPNVCvmhHN8nR9hP8lSSqVT1PJVST2EqYdzkYPEqScPRR3qfkxppJjGz4JJEk2aTh4hW KwPzuW9tfWxDudmyPRs+sfJENiTH7GPJO49tInR72Gyt0wMEeD2tKSYoqiqxH+Kp4GjZwqV+ DFBoe8pzZPT1/rrvbTbW1bNnG+MzgexIqhThgdXom5up0bmij1vUnCbGyc1Ju3YTZww6pGxT ZNJK2TZpWObduNmybMblOrZwNnDdWyYVjDZ/ex5KQ3dXDQ9isUpWxRWxFIYBYgrDhTZ0QqQg mloO5jsypISoeR8gwsGZ+2SOrqu4NiJjwjq5NzMVtWH9qpKmzuVSqcKGNkdXijhs4aTgxzfF WwdB3OTkrkO8qWy2VUxasmDk+pyGhzaRu130vIc3ymFvqg1qlY8K1qmFvVBKNTptpoQ7j1Dc m6HA3Sfa8jc+j1HecHZ4qnon2t272sMBunQTEE5sN25Nkmkhu7z9aFE7mkd5hU9GIVUlI8Uq e+/slZcln4i0VuTdO82NjzCIYGluLIOAdI5g4AZCYNMMYwxwk2SRpI0jwVUhsjEjZ0YiTFSV U/MNncd6oiT1HCcEo/UOBRQUTBqE/n2MT66VoyRUrMoZR1X9O+i9X7V777F4nZ9wYk0pwUpT ElKFSMVORhMNMNW2qNFVClSqqp/Unsdvrt9SqVKVZcYzGMxmYZmO7rruuu62u3WZYOruERXS JEI7O2bLNsuPaoszNszNuIzWIYbzuLZklDJKEmBLLba/rDdjR0cGat9BuBrVv63oOSfJJ+Yh yehJ7ysTxUNjT5I96T9bdo6IViVGJO8nuUV3Oj38nZufmPp7La6ly2sLltYbJXvdSo+p7XJv bYyZZZNi6t0cNClbtjcmzYqTGMIqKqoSYwOBDSUc0gwTwSvreB6PI8CYkPFEr6nDZHMkojyV PYrkqRUVyewbBsbOSSPFHm7yeb0KpRXpZbTG5u1q3YxGmmxKP6DmR0SipFAcJOYKmIJuY9w5 EbH2uRu96IxipTSVO580mD5D3iihRNgfiqJ/IqTwJPQnonNGx976JGh+CnJ1MUrA708HqaR1 3tfbvmZI00aU003bMYwxU2aVHxV633KkiqROaQ0n4kToxPUKUNkwidmzo2VFeAUn4qKqMQTh iU2MJhMbNkPcJNhHVEVIejvEo9zDEKj8nsTk3VPcVpDkSTm+TvJ60fmeOcZmVThinDDZsY2c NmyqqqqKxuxNGyqYmnNs6u4SlQpSqH3E7h0fc9bmR8H7BVH2nZHgn1pVRSMN3Dqx3pXe6KH0 P8ldXxOTQxG47lhbaSmH3iHc7JyR9ajsr5uoyn5Y7VV+FzYza6qrtcrnmZmDc+5wxs+srB3k qpjqVJNPokjm0zJjM0DkUlJs0VNBmjGKmkcbW6EaSVoSK2KmmzAVJzbCmg8TW5XVibI5piuz dowxMaYxNytGk2aNmhiblMaY2UrQVTGzGDG79sEk3OG7hpppobpTGyo0aNKmjTZpoVKoqkbE wrGEVSqlbKKxMaVhXcV2CRsKnNP7Bsc3o7n7HVuElUSTsqCc4dAWRQWTnZLRybGK64xmNvCW w5po2PFit7Nelo9zV4vGLR43L3qLK+QTCE0o5u8pOGyuDdGKlbMSYomGMRo8WjSSubBsrSU5 uQ0jA6NJsK9H0UfFsbG7FdypWmjFMaNkcOExpuUc1U7la5PDDTZjHZiNSjVVY6tbNTcXhmRw 3YxuxGpRqqscNbNTcVxbx2aTg71PU+0mGjDDRG5ySSacmJ2SU5oaSVE4YxObBwBzUm5jyeBu miOr9DHJBKJ4H0STkUfQisdGIYkUpKkpwif9ichhipHJJ4FdjxK0rk6GO5U8kbnYfU/M5sex hzCScOiRUjGCEkxMIJPyUYqlScMV+DtNcS5clhTGMK3aDTTTCpVaYrEpimmj4Nka2bJpXwUr ExNmyKrTYxpsrmrRVK3YVSjGKY2SInQdyH61QqVKwlCUwnxYe0fsfW9ZJGzmKP5XsJ3tPEex K4RsqeKk4Yn3ofxqEqpCtG7mfNhOSTybJ71YJPqMYv51qHxBioW1czKuYfBGhMKmmzdWJNPi 5MODk0jDk3NyFFbMYphhsqbkw2btE2Vo3CqlaaY3KbNj9bZhWptbMVWysbMTDZTTExho3SYk rG0NpbGxpGDSVKrRWMTSbBhMVGFYxjGzZVVWjRsYbNFbQqWjRWkU0UlVpNGwYIqsVMYaTYpM KU2MMYcOZE+p+zvt8zm/S6MU5FFUR4qfoJXrVuVsPNT2BVTFEIWrTZ1OaI4Q+hwVGhpsklJu 0IY8So8UkQqdd7cFJ625WqtTDGMMJgrGlYjkmmTlb5Grba/GqjYiy/l2U1y5dXXWU2LraylK UyzLZK9pSjZFGKJiTFQrGUNtjLlta0k1oy5bWNhHBEV9p4h6SK8VPFjT4seQ3Yrmrkic1bFF FUrDkbubHkw0IlcK+pJ5k0JJ/E/akklMN04SHchU/Y8E3TsxVQo3PtUp4juSfrScj09tseZp 6nVO8iUToj84Vu8QQxUqUqpFSiUioKKpFJJUQIw97RHqNkOQf4qid5Fe0ruVJGE+0Tg6NH5k HCcJsSSfqV1GkkkjubpiHyQ6Jp4vBNJ9HyQwiSOaN03ISGgbKVUgqFSRpSTkpU2YD2JVN0cJ OElRIqGysSqQnVUSfi6myI0SfU0SsOCPIU3dWxMVR0RiSk3SJId7mTwE5kc3MxHEuZmJztrS aUwitNMaRopjTEKmmGipQqpKUUUpUk7E2Pi+J27bfLZ7t7z158fqrfY1y+WZn6X1fW5pj9/a 75jJMmeav+/fNYjt2Dc12Y+27vMZJkzsr7b7aMSVLr8k7otJV3eZeYyYnknJiiPJumOjTCBN kVJGjg9HVUmPFuRxreVan9fgzLM3b63lWk23rMsypatLW6Q3Hijo5KoaJ2cJsaeY5HIxGzQn erhw2StJunYxoc2OrSHRObxSuH6imyVVVwnDdpVbKmxsejdu7O90eTG6Niv7FciuVtg9To9R sO5Obo0nqOidGjdUY9j2GmyuaE3PBo9SmHoxu3expI6N3B4cW8Pvadzwdxlt4bOj1Njs9G7D ycnm/Yx2bkquZ4sDmbvFXZsrk2abPJh3qoclYMcN2jcrGJjk0MKp0bqrk5Gm40rZTcFY2cNm FbFUp0VipuVMVzUVwY4Y2aTmkoqpit2zRuU4eD2qxybDxejDQ2VyV5q3K6uyuSuHIxhunRua cOG7zVs3bO4xwczdRwrY6PB0dHDdzTq03bN2zZObsx4CNw7nIhiVQqD+J9Z5vFuN0xicmmjS Gu+llu1GFVauUYtkUtWFLVKVKc2n3mnBuMWFmpkkVSV8tfLd4QyZQwhSZQsMwyt7rd7z43Xt V7HCehhJj2Obo5Ju3YwlTCjEUrYeDHCo2eiphulSQYoIaEAFVDy8LnmroRSJakq26EUgxK67 JQECBAjR8SzYVw+c8vRLwWfEuW27C8Sy8wzMzMMzDDDAwwqjuXSSSSQhFe1d7dnwVsHsCjwP IUwYDyG4CBB8DRrzD3nc7CEMNTifjxKtK1PQvBSkWY2ndyrStSYLBSkWLoQBZ2NHsTHBExNJ uk7iYg5Pa2SJoqUNnUmCaRurhNBu8GD6h9o0P2vqOzRGJPiKooOb2GJsncQ3MSMJUSNFME6k hpo+s2H8CK8T0YTZ3uRodZJHFElsgpVK7mJOikkxMViTStNjuVsTZubqaUm6pMbJiaViVsmy NJBsmyzLLGKMTGFOD0Ud6lT9T8U0OwU3UVVTgPUrmIqY2e73rXJgq4tY0leZh2VOr9iYTzH6 jHJK5PUnhbfmckkjo9aSeJPGn9hUSI6qk+CRuk0ek4t9ak4Yxpkn0I6qcArsSg0aYh2JiUpo rTDJbaUTSMfJMYNE/I9YmhSKKJSY8x6CjcbOo+B5Hcd54o+apNyo5uaVDTExokdGiDveZO5J 5urudHicyYrD+07zRsjqdbyt76tVt6ur8V2uQSkEK1VR3o7KPacK7kPN7XJ2eA03O52bnDFT uHIxIe+21VUqjE+pOZOiVIlSSSqpKkFWy2JOr0TxJyfrOZhzPJDmetSEk2ebAe91Rslbmydz ZwR9T2qNIxXIVHqSEgugDfEesLYpg2xQFYJtkHeIrjfIzMaVq21SSvU2JKHA6CiiKIwaMGhR RFEo0mkmlJXRjm9aQxN2w8U9ifwOg8x3IK/QYjFSTCk5KkeantWRtTGsaKqLRGKlK29pVvz5 R5LCrBpGxhJKjGOTxw7laViuatyVJ+k2ZPZVue405PQ7J1dVbqxRyxzU3cmjgpUio3GNMPQM 3t9ojTdwaGk9SUhT8pZbMKHcY6OQ2DSxVjZSYqDuL1LepbepJjRaTaZpluutKVSNJFTT1ic1 GjhSipP1tNNmzcqq2fixuU/WqqVSqowxi2222QqhTFY96ox3u47jEfkkNibJVO8Ye9u6HJ7z 4HvLczMzMzM05N1VVSuESnoOiSSPJNMFTwUYcNkrSpJjGNGMTSFFSVGJpMYaiW2oKpVYmKoY lUVUmJMH8BiYVVFGiZ9SyqaG9WQxjoiOhjRXBUmn0OA0qpwqT7Xixsrkew4dDrVVa4UUcKe9 h4CUiYH4uDocDcrE6g0xgGhMVEYBgiAhEIuFoIcXAjirUzXibUUQiC8YrAxTPwr5IZ11a9tj ve61s1mrW6CKgTcKQH0lQKPidxzcI3c0nZXZ0I3aDRpXe8HekYqqkTZO5UqVIpjRppRUAggN +V7Oi7uy7VLzEaKDCkUB0I5kUqUh0DkVTk7zDTzU5ngg6nJNkzLZUmFV3sbuSbo3SeDTY9an Jum5Um6NjhVY3SStNnYUmm7E05ugeKFcOibjmjZsdGieIbDTkYcOqdBzOb5qlfpdE7Nic3Y5 nNsk4cncadyu46nRwNjoUnUT0f2GnMqSjcrs04SdWJJodzdp1cG7sVsxpBVadzhu7Ordpwdx 0ehzckrkdVNJzbK7Y6NnCtmOjq5t3Q6NOps06sd6pisVpWh2dmO872x38kdhRjRjs5HRo2EY 4cOG6txMExw4czZDk2cmhjZpu5G6t2mzkYU2bqSuilbsI0leDh0c2zTdEmNHRXR4kmPFW6MO zm0bFTdO43cODcOSobu40nRyaOrcock4claejdyOypw4Vo5tk+srh5uG7gNDq+9u8nc6PB0Y TuasWx1TcxOTRpAcEY6IwxJ4J6O9pu0pzaHNHViczonM/uSTzpSllStnU2cnU9RXoonQkrsO 5GIUSOEbJsYHeqdSjqNzEN2kRo9rAhRRgWYPucep0eE0d8hp66q9G00bupULbXqhoRG1E9iK 6OE0Y0IY2hIwrOMGNg4HRqGk0NYIrDo0Q2Zv7XnOG5GkSvhj4+cfM2uIcjSJXMfFaVWqFUnD DuaCRyNnbWMy6t5uTDmm6YqcHU3KaNEqaRyKYaJzdmOTE8G7kOTdo5tEYqcmmk2KkEjkXXZC Om0IfQhmjhD3kLQq7mjDgWkkID0SWJKoqSCN03kSwWK0CWLMeLelu933xurdRVbq3buxyaQt lsFsLZK7MMVJbyZmO2upmYbuCIB3O4AXztTbpgg2HYlcWcXT7fJmV284LRw+Vj0s8n1M9NSs Ttd3rvmV37wWi64d4OLO76md9B1NVmNmW/SavKzTZloen6HDDgIVJwSjxK6pOG7mKTkio2OG G4qtEOgeLHNE/OKTc4Ogbp0J1dGkiugchyScOYbnBHZuf0uRMSGx0YrBimKiyMWuYw2Hm5tz hU0qc1I7ySeBjcOSuhpyU7ETSTZuxsSc1RJDucg4I9pEclN1JioiVITobHgS5mZmZmZlBzkt nkyp5k07JTqbMVUaUgxTZJKV9jNrfQQ2E5KiOZkQIOBwHoCCd+MiKwgpBXMdZ6nNu7JOqsH2 tmCSHic00gpXtVDCtiJOaJTzR0QVUchiqQwmCHkhsadSm1xmYx4qfgbMV7GJJurRW6mFTc0m mhMbMQ5q2VE4YkkwqsTFVjGKxUMYqVFplMpljExu0kMEUUkcjqm44TkqpEqEqVUVVVCMHXlx 64Mo1mtQZRpmlrDE00YYmylc2ni4OjTkkMR9ZVVVHmR7nCV2YcI6LMtndw+J1bMVBsUs3Y6J o6Ek5PcbpDhU5vIKquZP0sPY3dWJT1pXCDQ4U2bFMDdK0zVW7mFeZyKSqRVUYkj7lCSeakkY qQh5purdXMrGyJ6P3Nmyo2JuSR3sY00xoh0Ug5uo/OhO52bCnVJE9ipCtjA9qTzcB7x0cLHa 3HY1VrZXU5p63ZXVjsxpitNnZs73ZwpPdvvyutZqxIqiklVorCqioqlKVOSKxNBpppWmlaSa GFYxGBjZpqauXFzKxVGmiRNF0zMZWVaiqrFYYrErAqRu0YTGIxs1CJ+DvTQrm4aO54pJU5Kq hVSlPNCpFUqoKSpKUlKQoopJjFVMKHVWio5laRhzdkh2I3J3jgUadmHVJ4vedBokTZ7nBhKc 1DCUiqSh3PeN1SJu738TGO9EeYqE5tE/WaVOx8GnCHkckTTuJMARj1mkxRSoh19eMzEr2FYq p+Zh5K0nJR5va5OHo5OTscnN1VN1Sc3Mp8xpMfY3Gle79ds+KSSeSoioqmhVafF9g97TZiN1 J6wfkodCnomKr1vYPa8k9alex5uGzmiUlHQThUqlMJCTFQ+bvObsknJSqko9rJ87aYk6Hiie sqc0w7wf7HCeCRKVU/Y0qse8NzY5pzfhBJN0+inAYROT1B/4iHikr4Ho+RXRUnqSQhpUqg8z 5pIQ9rTm3V/Ju8ElaV1GE/adyo7KJVT/ydjyPQw2cidDqfBP/J4NHmkQ96JNDdJ3vkhB8nk5 jZ8hX+dzD2J8Xodg7k/wSaPsdTDg+J9bds+Q3Qej/O2TD+JKmD71VVU3CvA8wwk5pOiTGDFE lIn6mmmiKRgY0UTCaJEVUSsRQ0wk/6v+u3Ymm6pG61Y00xGFVClFaVMVClQqq/eqMJK2YGKT GDSqrERUqRKlttSaDHokKdDGPcfoYJjCFEqUObhVQwrD98ZkpTIzJU3KlOHiH8LwR1E2RHsS Vw/AxJIknZH7Xxc2iqN0rBTByYk5N0/I2TYkJMTCEhzf5nNiJu5GKfYlKqSqSqlT8DT9rYPt V+JUkfFEQo9zBiTm/M8FVUSkjNWyToh4u9/V7H4JSvHi2EqVVdCsUYoknokkmOiTSadkU7H7 UH3vMJHEebqwx+BUeilUNJsxPa000kxJO6nerVWQ7PURpuYlKstlqLbdGPYe9iJiT8XN3hyK ifJiTq3SFcxjo9Dti1iJR/OqNKjZUjYKGKepjSJsbHJyaKYm6UKqOajZwN1TTRuh8HCbKpN2 yvB5G7dzcw5JXQbp0N2yQ7zZ0CqleYKIP0pJKVIY/hyWK1JECEFTkZIrvEEsg5mYkKCDEqGJ KCbNExIk0jY2KVuqqblVH9JG5Iu9ukqFBSqqUqpKj8UqpUxXDhGmibtJWNCqcxUkbI0xgqVK /vFNJokpUP6xNNJKVpFiTp0jGZlKxNjE2JzGNFUlJQro2aVVaVVVNNNNJG6FPiSVNkpJq3o6 1drka36UtUGsrbzYYr+FTFYqbiSuSTd4ub7Xo9E+5UT2lSKU+Koxox/mMTE0P2CpGOjuOgdH 1PgbIHeoqohurk5pDAkqn71HkopSqnqSiSqfWlJJwfUTuR0IbCNjqpI7juPqbocO9MJ7Hc9j R7FTEkn7DzNAQDZ4A+AbD2FV6HwEB9Z+aRyKRyNuhl3dXcu6u6qn2r74s+I1jgDSHMdo84HZ LDc+ihyT0fitXxH0TYUpVOwnk5MN2PJSqbpHcSdqqkD/ikQT2D4D1iiiKJpE2cMSA6oaOZEj YKT5urSOAr+kqR+cpFaIIrYobAoFNnUdwLBPhPmKAVDMFPcd07AMis3tztFFzg3qvNlZ5lFz POs0wmlbRsLbRbVVMH9bY9TdjdpNGlaNzZ2aNlDZjopitN2jGnCtlNlTT9zDkcnJpIY6sODw abngqtmN2zDTRyU2aMdVYww4cKrdRTToiuFbKqRSuFNJpw2dUbmyVXvY2adnmRDZ2cm4qjub NGmrbhoYxdW6O5zYfgrZuYThpvGrbbZFKttqtHIph0KnVU8FSObnLbVchySV4o6I3dTsUTsf 9ZRGEHJyCOSRzQnUn+Dh+dTdQ/lVJInoidzkbn8T2n4uSfpcmk5PB6z4JzEDzPik0fgc07z1 I9NrZpk2kCmm0IahAmLItRWNUlb9S2prru1XNtrmuu612mTaQKabQhqECYsi1FY1SVutqa67 tY3XdV+Brxrc1zVtImtpLbfw1pYW0CFV1dauIqSlQKqIklEkpUKopIT2HuTD7FREm6FltstS rLZIi/pfj7XK1r5O121ekjzsNqWrsGLJjTMaNIulU2mxsku7z12uVrXrtdtXpI87DanY0V11 U2mxsku6FBrGD5PPPCg1jB555Zdd6WMDZZQC4VLYHwymqAB//F3JFOFCQakPpQQ= --YiEDa0DAkWCtVeE4-- From nobody Sun Nov 9 12:20:19 2003 Path: main.gmane.org!not-for-mail From: Don Armstrong Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 01:58:31 -0800 Lines: 54 Approved: news@gmane.org Message-ID: <20031104095831.GB2707@donarmstrong.com> References: <200311040525.38465.russell@coker.com.au> <20031104085326.GA15270@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+" X-Trace: sea.gmane.org 1067940043 10913 80.91.224.253 (4 Nov 2003 10:00:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 10:00:43 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 11:00:41 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGxzN-0005xd-00 for ; Tue, 04 Nov 2003 11:00:41 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id A53381F8EC; Tue, 4 Nov 2003 03:58:49 -0600 (CST) Old-Return-Path: Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [138.23.92.77]) by murphy.debian.org (Postfix) with ESMTP id E5BF11F8E0 for ; Tue, 4 Nov 2003 03:58:38 -0600 (CST) Original-Received: from rzlab.ucr.edu (localhost [127.0.0.1]) by rzlab.ucr.edu (8.12.10/8.12.10/Debian-4) with ESMTP id hA49wVNM030981 for ; Tue, 4 Nov 2003 01:58:31 -0800 Original-Received: (from don@localhost) by rzlab.ucr.edu (8.12.10/8.12.10/Debian-4) id hA49wVcb030980 for debian-devel@lists.debian.org; Tue, 4 Nov 2003 01:58:31 -0800 Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <000901c3a22f$b746d0e0$c90111ac@netservice.corp> X-Face: &M"4U@"QPr*4J='o3uX!C)l^-k6eODr4^>[lX^"g,Ac,>H~+.>_A4bk/GikjcXy?kOy-OitMH)J^MzgI",O5FjF,BxntA-z^KXVP9#enwq2X[^'f9tynS2@L0+'sQ"eh+LxX4R}"Xzd6BNr8.@Wu{jyNx|]tJG.*H^IDrsA%3 User-Agent: Mutt/1.5.4i Resent-Message-ID: <2hjw5.A.1aG.Zh3p_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155006 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 03:58:49 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44390 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44390 --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [NB: When reponsding using the web archives, please get the References and In-Reply-To: correctly. You may also consider setting MFT:] On Tue, 04 Nov 2003, Peter Busser wrote: >> PaX would take much more time so I can't do it. >=20 > You cannot do it or you don't want to do it? Russell has made it adequately clear that he doesn't have the time or the desire to deal with PaX at this time. As a volunteer, that's always his prerogative. [As a side note, if you are trying to enlist volunteers, I strongly suggest not berating other developers while doing it.[1]] > In fact, anyone can do it Russell, I'm pretty sure even you can do > it: Why not volunteer to make the .deb, get a sponsor and get it uploaded then? Surely you have more control over where you spend your time than how Russell spends his own? Don Armstrong 1: See the mplayer saga for a relevant example. --=20 Filing a bug is probably not going to get it fixed any faster. -- Anthony Towns http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu --jho1yZJdad60DJr+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/p3hHgcCJIoCND9ARAo3rAKCTeyRBKcuzx2Q0fP1N2/d16fUq+QCgl231 M5I1W5oSggi+Ww9BWGkFGfM= =N0fq -----END PGP SIGNATURE----- --jho1yZJdad60DJr+-- From nobody Sun Nov 9 12:20:19 2003 Path: main.gmane.org!not-for-mail From: Lukas Geyer Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: 04 Nov 2003 09:17:53 -0500 Lines: 30 Sender: Lukas Geyer Approved: news@gmane.org Message-ID: <87ekwomd4e.fsf@lgeyermac.math.lsa.umich.edu> References: <20031104085326.GA15270@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067955819 14510 80.91.224.253 (4 Nov 2003 14:23:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 14:23:39 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 15:23:37 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH25p-00046r-00 for ; Tue, 04 Nov 2003 15:23:37 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id B86801F820; Tue, 4 Nov 2003 08:18:08 -0600 (CST) Old-Return-Path: Original-Received: from lgeyermac.math.lsa.umich.edu (pm484-42.dialip.mich.net [207.75.181.52]) by murphy.debian.org (Postfix) with ESMTP id A67931F544 for ; Tue, 4 Nov 2003 08:17:58 -0600 (CST) Original-Received: from lukas by lgeyermac.math.lsa.umich.edu with local (Exim 3.35 #1 (Debian)) id 1AH20I-0005hv-00 for ; Tue, 04 Nov 2003 09:17:54 -0500 Original-To: debian-devel@lists.debian.org In-Reply-To: <20031104085326.GA15270@adamantix.org> Original-Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155026 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 08:18:08 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44410 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44410 Peter Busser writes: > > I volunteered to make a package for exec-shield because it meets > > the Debian criteria, I have time to do it, and it interests me. > > PaX would take much more time so I can't do it. > > You cannot do it or you don't want to do it? In fact, anyone can do > it Russell, I'm pretty sure even you can do it: > > apt-get install kernel-source-2.4.22 > cd /usr/src > tar xvfj kernel-source-2.4.22 > cd kernel-source-2.4.22 > wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch > patch -p1 < pax-linux-2.4.22-200310051430.patch > > And now you can make menuconfig etc. Now, that wasn't too difficult, > right? If this is your idea of maintaining a package, I am glad that you are not a Debian developer. I hope you take better care in putting together Adamantix, otherwise I pity the poor souls who use it and believe it is "Trusted"... Lukas P.S.: Why does everyone attack Russell these days? Seems to me like the field of Linux security is populated by lots of trolls. From nobody Sun Nov 9 12:20:19 2003 Path: main.gmane.org!not-for-mail From: Russell Coker Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Wed, 5 Nov 2003 02:27:09 +1100 Lines: 53 Approved: news@gmane.org Message-ID: <200311050227.10262.russell@coker.com.au> References: <20031104085326.GA15270@adamantix.org> Reply-To: russell@coker.com.au NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1067960029 25088 80.91.224.253 (4 Nov 2003 15:33:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 15:33:49 +0000 (UTC) Cc: Peter Busser Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 16:33:47 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH3Bi-0001DB-00 for ; Tue, 04 Nov 2003 16:33:46 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E7EDA1F8B1; Tue, 4 Nov 2003 09:32:33 -0600 (CST) Old-Return-Path: Original-Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by murphy.debian.org (Postfix) with ESMTP id 63FE21F51A for ; Tue, 4 Nov 2003 09:32:21 -0600 (CST) Original-Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 3071F9260A; Wed, 5 Nov 2003 02:32:20 +1100 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id CA8837F003; Wed, 5 Nov 2003 02:27:10 +1100 (EST) Original-To: debian-devel@lists.debian.org User-Agent: KMail/1.5.4 In-Reply-To: <20031104085326.GA15270@adamantix.org> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155027 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 09:32:33 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44411 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44411 On Tue, 4 Nov 2003 19:53, Peter Busser wrote: > > I volunteered to make a package for exec-shield because it meets the > > Debian criteria, I have time to do it, and it interests me. =A0PaX would > > take much more time so I can't do it. > > You cannot do it or you don't want to do it? In fact, anyone can do it > Russell, I'm pretty sure even you can do it: Actually I have not tried patching in PaX on it's own. I tried GRSec and=20 found that the conflicts were greater than I could fix in any reasonable=20 amount of time. During the previous discussions on grsec I had got the=20 impression that PaX was the hard part of such a code merge, maybe that=20 impression was incorrect. Also note that I use LSM on all my kernels, so anything that conflicts with= =20 LSM is something that I have no ability to test and therefore no interest i= n=20 maintaining. I'm sure I could get PaX working with LSM, but it would take= =20 some work. Anyway I'll look into this matter after I upload an exec-shield= =20 package. > I'm not in fact trying enlist volunteers. I try to offend as many Debian > people as possible, so that they choose exec-shield. This to ensure that > Adamantix will has an edge in security over Debian in the future. And it > seems to be working very well so far. This seems to conflict with your web site. =46rom http://www.adamantix.org/motivation.html: # That is why I started this project, to create a secure Linux platform and # make it available to everyone. Yes I know OpenBSD exists and I think they= do # a great job. However, free software is all about freedom of choice and it= is # be good to be able to choose between different highly secure systems. In a # sense my aim is also to create a reference platform, so users can ask Lin= ux # distribution vendors: ``Why don't you provide this?'' In the future I wou= ld # very much like to see that this project serves no purpose anymore, because # some or all of its ideas ended up in other (more mainstream) distribution= s.=20 =2D-=20 http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nobody Sun Nov 9 12:20:19 2003 Path: main.gmane.org!not-for-mail From: Peter Busser Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 11:29:52 +0100 Lines: 69 Approved: news@gmane.org Message-ID: <20031104102952.GC15674@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067943147 17882 80.91.224.253 (4 Nov 2003 10:52:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 10:52:27 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 11:52:25 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGynR-0000Qj-00 for ; Tue, 04 Nov 2003 11:52:25 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id EA9161F931; Tue, 4 Nov 2003 04:50:59 -0600 (CST) Old-Return-Path: Original-Received: from mail.adamantix.org (unknown [212.204.216.41]) by murphy.debian.org (Postfix) with ESMTP id 840BC1F537 for ; Tue, 4 Nov 2003 04:31:24 -0600 (CST) Original-Received: by mail.adamantix.org (Postfix, from userid 1000) id 9F2646B649; Tue, 4 Nov 2003 11:29:52 +0100 (CET) Original-To: debian-devel@lists.debian.org Content-Disposition: inline User-Agent: Mutt/1.3.28i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155009 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 04:50:59 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44393 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44393 Thomas Viehmann wrote: > So, please don't start insulting and accusing people for doing good work > and proposing to do even more of it. If there are technical reasons that > cause you to prefer that exec-shield does not become part of Debian's > standard kernel, just put them on the table, but save us your conspiracy > theories. I have seen noone accusing Russel from doing good work. The problem here is not the good work, it is the things he says that can easilly be proven wrong. For those who don't know, Adamantix is a Debian based distribution aiming to create a highly secure Linux system. Most packages used in Adamantix are Debian packages, including the kernel packages. Almost all packages have been recompiled to make maximum use of the features PaX provides. Most programs run fine. Only a handful of programs have problems. PaX has been a standard part of the kernel in Adamantix for almost a year now. And it is used on mission critical production systems with SLAs. So what are the facts: - PaX works, even on Debian kernels. Adamantix proves it. - It provides more security than you get by installing the latest updates: http://groups.google.com/groups?selm=20030525190037%2470c6%40gated-at.bofh.it (Also proof that it works with Debian) - It takes less time to apply the patch to the Debian kernel than the time that is wasted on this discussion. - The functionality can be tuned to specific needs by changing the kernel configuration. That means, you can lower the security at a level comparable to exec-shield if you want to. - I have installed an Adamantix kernel on a Sarge system and the command line stuff worked (didn't test it thoroughly). If packages follow the current Debian policy, they should be mostly okay, even if the most restrictive settings are used (like in the Adamantix kernel packages). - You don't need to recompile if you don't want to. It only adds more security if you do. - PaX is available on different platforms and not only on i386. That is, Alpha, PowerPC, HPPA and others. - The design and implementation of PaX have been documented and are open to public scrutiny: http://pageexec.virtualave.net/docs/index.html This includes a description of limitations and design choices made, so you can find out what trade-offs have been made (or haven't been made). - PaX is independent from gr-security. And can be downloaded and applied to the kernel without having to download gr-security. - It is POSIX compliant. Programs that break are those who try to go beyond the limits of POSIX. Most of them can be fixed. And those that cannot be fixed (like the Java JDK, which is available as binary only) can be made to run without much hassle. The package maintainer can take care of this, it is as complicated as stripping binaries. We're talking about a handful of programs here anyway. - It is possible to have a fully functional distribution running on PaX. The OpenBSD project proves that, it has features similar to PaX in the kernel, and you can still run all the goodies. - Running paxtest shows the differences between PaX and exec-shield. Everyone is invited to run paxtest to see for yourself. So far I have heard a lot of talk and a number of opinions on why PaX is bad. But no proof. I can reasonably proof any of the above. But I have seen no such proof from those who propose exec-shield so far, only opinions and cheap talk. Opinions are like assholes, everyone has one. It is proof that counts. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ From nobody Sun Nov 9 12:20:21 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 12:39:10 +0100 (CET) Lines: 91 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <20031104102952.GC15674@adamantix.org> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1067946497 25425 80.91.224.253 (4 Nov 2003 11:48:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 11:48:17 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 12:48:15 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGzfS-00033d-00 for ; Tue, 04 Nov 2003 12:48:15 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id AD3211F95A; Tue, 4 Nov 2003 05:39:38 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id 065591F4B3 for ; Tue, 4 Nov 2003 05:39:10 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id CDF7B4B030; Tue, 4 Nov 2003 12:39:08 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 836711FC2; Tue, 4 Nov 2003 12:39:08 +0100 (CET) Original-To: Peter Busser In-Reply-To: <20031104102952.GC15674@adamantix.org> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155011 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 05:39:38 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44395 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44395 On Tue, 4 Nov 2003, Peter Busser wrote: > - Running paxtest shows the differences between PaX and exec-shield. > Everyone is invited to run paxtest to see for yourself. the reply below mostly a re-sent of a mail i sent to you privately - but you repeat this argument again without any apparent answer to my counter-arguments. Summary: i can see no significant differences between the paxtest output - all the differences seem to be bogus, see the details below. Here's the output of paxtest-0.9.4 under an exec-shield-G4 kernel: Executable anonymous mapping : Killed Executable bss : Killed Executable data : Killed Executable heap : Killed Executable stack : Killed the above ones are important, exec-shield catches these exploit categories. Executable anonymous mapping (mprotect) : Vulnerable Executable bss (mprotect) : Vulnerable Executable data (mprotect) : Vulnerable Executable heap (mprotect) : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Executable stack (mprotect) : Vulnerable i do believe the above checks are bogus, please explain to me why this case is important to handle. the test checks whether it's possible to execute an area after mprotect(PROT_EXEC) has been called over it. The answer: of course it's executable, the application asked the kernel for this! Any exploit that can call mprotect() has free reign anyway. The ability to execute a library call or a system-call is End Of Story. Why is it such a big issue to inhibit mprotect() calls? Especially since not honoring mprotect() calls breaks existing apps and specifications. if you can call mprotect() then you can very well call munmap() and mmap(MAP_FIXED,PROT_EXEC) as well, which is equivalent to the mprotect() call. From whatever angle i look at this test, it's bogus. in any case, the above restriction is trivial to add to the kernel but still i didnt want to add it because it's simply pointless. Anonymous mapping randomisation test : 8 bits (guessed) Heap randomisation test (ET_EXEC) : 14 bits (guessed) Heap randomisation test (ET_DYN) : 13 bits (guessed) Main executable randomisation (ET_EXEC) : No randomisation Main executable randomisation (ET_DYN) : 12 bits (guessed) Shared library randomisation test : 12 bits (guessed) Stack randomisation test (SEGMEXEC) : 17 bits (guessed) Stack randomisation test (PAGEEXEC) : 17 bits (guessed) these are acceptable levels or randomization against remote attacks, except the ET_EXEC one, but ET_DYN is used for PIE binaries so this is not an issue. Return to function (strcpy) : Vulnerable Return to function (strcpy, RANDEXEC) : Vulnerable Return to function (memcpy) : Vulnerable Return to function (memcpy, RANDEXEC) : Vulnerable (these can only be caught via compiler changes, clearly not a target for PaX or exec-shield.) Executable shared library bss : Killed Executable shared library data : Killed these are caught by exec-shield too, and are quite important categories to catch. Writable text segments : Vulnerable again, i think this is a bogus restriction too. Why deny writable text segments? Control over the application at such a level is Game Over in virtually every case. summary: exec-shield catches all the non-bogus categories and tries to raise the bar of exploitation, without breaking binary compatibility arbitrarily. Ingo From nobody Sun Nov 9 12:20:21 2003 Path: main.gmane.org!not-for-mail From: Peter Busser Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 13:31:35 +0100 Lines: 32 Approved: news@gmane.org Message-ID: <20031104123135.GB16244@adamantix.org> References: <20031104102952.GC15674@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067950467 1361 80.91.224.253 (4 Nov 2003 12:54:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 12:54:27 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 13:54:25 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH0hV-0006cT-00 for ; Tue, 04 Nov 2003 13:54:25 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C587E1F8A3; Tue, 4 Nov 2003 06:51:08 -0600 (CST) Old-Return-Path: Original-Received: from mail.adamantix.org (unknown [212.204.216.41]) by murphy.debian.org (Postfix) with ESMTP id 2566C1F406 for ; Tue, 4 Nov 2003 06:33:08 -0600 (CST) Original-Received: by mail.adamantix.org (Postfix, from userid 1000) id DB6056B649; Tue, 4 Nov 2003 13:31:35 +0100 (CET) Original-To: debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155016 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 06:51:08 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44400 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44400 Hi! > the reply below mostly a re-sent of a mail i sent to you privately - but > you repeat this argument again without any apparent answer to my > counter-arguments. I already suggested you to reread the PaX documentation, there are the answers to your questions. There is no need to copy/paste it here. > Summary: i can see no significant differences between the paxtest output - > all the differences seem to be bogus, see the details below. Fact is: There is a difference in paxtest output between PaX and exec-shield. And it is not a difference in exec-shield's advantage. Another fact: If you don't like this difference, you can change the PaX kernel configuration to lower the level of security to the same level as exec-shield. You didn't touch the other facts in the list, because you know you don't have any proof to easily dismiss them. You would be my hero if you succeeded in improving on PaX. But in all honesty, exec-shield does not do that I'm afraid. In fact, there is simply no technical reason whatsoever for exec-shield to exist at all. None. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ From nobody Sun Nov 9 12:20:22 2003 Path: main.gmane.org!not-for-mail From: Andreas Schuldei Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 14:10:55 +0100 Lines: 13 Approved: news@gmane.org Message-ID: <20031104131055.GA9298@lukas.schuldei.com> References: <20031104102952.GC15674@adamantix.org> <20031104123135.GB16244@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067953142 7883 80.91.224.253 (4 Nov 2003 13:39:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 13:39:02 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 14:39:00 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH1Oe-0000wm-00 for ; Tue, 04 Nov 2003 14:39:00 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 305961F7FD; Tue, 4 Nov 2003 07:31:13 -0600 (CST) Old-Return-Path: Original-Received: from petrus.schuldei.org (petrus.schuldei.org [81.27.1.16]) by murphy.debian.org (Postfix) with ESMTP id AC4711F7E7 for ; Tue, 4 Nov 2003 07:30:55 -0600 (CST) Original-Received: from lukas (lukas.schuldei.com [192.168.31.10]) by petrus.schuldei.org (Postfix) with ESMTP id 7EFABFBBCB; Tue, 4 Nov 2003 14:30:54 +0100 (CET) Original-Received: by lukas (Postfix, from userid 1000) id 9709F64098; Tue, 4 Nov 2003 14:10:55 +0100 (CET) Original-To: Peter Busser Mail-Followup-To: Peter Busser , debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <20031104123135.GB16244@adamantix.org> User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155020 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 07:31:13 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44404 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44404 * Peter Busser (peter@adamantix.org) [031104 13:55]: > You didn't touch the other facts in the list, because you know you don't have > any proof to easily dismiss them. You would be my hero if you succeeded in > improving on PaX. But in all honesty, exec-shield does not do that I'm afraid. > In fact, there is simply no technical reason whatsoever for exec-shield to > exist at all. None. you seem to suffer from an accute case of hybris. i feel you are in the position to bring proof, if you disagree with ingo. He seems to have thought about the issue a minute or two and dislpayed some skill in the area allready. From nobody Sun Nov 9 12:20:22 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 14:41:16 +0100 (CET) Lines: 84 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <20031104102952.GC15674@adamantix.org> <20031104123135.GB16244@adamantix.org> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1067953343 8416 80.91.224.253 (4 Nov 2003 13:42:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 13:42:23 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 14:42:20 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH1Rs-0001C0-00 for ; Tue, 04 Nov 2003 14:42:20 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 38F671F54D; Tue, 4 Nov 2003 07:41:35 -0600 (CST) Old-Return-Path: Original-Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by murphy.debian.org (Postfix) with ESMTP id 670121F40D for ; Tue, 4 Nov 2003 07:41:18 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id 8EBE9440C4; Tue, 4 Nov 2003 14:41:17 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 38D0D1FC3; Tue, 4 Nov 2003 14:41:17 +0100 (CET) Original-To: Peter Busser In-Reply-To: <20031104123135.GB16244@adamantix.org> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155022 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 07:41:35 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44406 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44406 On Tue, 4 Nov 2003, Peter Busser wrote: > > the reply below is mostly a re-send of a mail i sent to you privately > > but you repeat this argument again without any apparent answer to my > > counter-arguments. > > I already suggested you to reread the PaX documentation, there are the > answers to your questions. There is no need to copy/paste it here. yes, i've read them, and they do not answer my questions. The PaX documentation says: Non-executable pages and mprotect() restrictions are effective in preventing the introduction of new executable code into an attacked task's address space. There remain only two venues for this kind of attack: [ write files ] [ map existing library ] this is plainly not true. Firstly, PaX doesnt solve the "write a file and mmap() it" problem, so what's your point? Secondly, you can eg. write a shell-script into non-executable memory and system() it. Etc., etc. The ability to mprotect() a page already requires good control over the binary, at which point you can do basically whatever the application can do normally. Arguing for this mprotect() restriction is like arguing that "i am only a little bit pregnant". The attacker controls the application and there are many ways to use that control to do Bad Stuff. The mprotect() restriction is an after-the-fact restriction that reduces system utility in a way that by its own documentation is an admittedly non-complete protection. In fact it adds little if any protection. Exec-shield does not include such arbitrary policy decisions. The attacker has broken in, he controls the app, it's just a matter of time until he owns everything the app owns (or more) - mprotect() restrictions or not. besides, the mprotect() change: Restrict mprotect() CONFIG_PAX_MPROTECT Enabling this option will prevent programs from - changing the executable status of memory pages that were not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory. breaks a fair number of legitimate applications, breaking binary compatibility, which is an additional no-no too. and this is easy. Breaking binaries and increasing security by making the system less useful. > > Summary: i can see no significant differences between the paxtest output - > > all the differences seem to be bogus, see the details below. > > Fact is: There is a difference in paxtest output between PaX and > exec-shield. And it is not a difference in exec-shield's advantage. this what i'm disputing, because those tests i criticised are arbitrary (see above). The other tests are OK and paxtest is a useful utility, no doubt about that! by your argument you could add this to paxtest: printf("PaX is inherently better\n"); there's no way exec-shield could get around this "difference in output" ;-) > Another fact: If you don't like this difference, you can change the PaX > kernel configuration to lower the level of security to the same level as > exec-shield. my point is that CONFIG_PAX_MPROTECT is not acceptable in a generic Linux kernel, and that there's no 'reduction in security' by not using it. If you can give me specific examples of exploit techniques that this disables in a way that cannot be worked around then my point is incorrect. Ingo From nobody Sun Nov 9 12:20:22 2003 Path: main.gmane.org!not-for-mail From: Tommi Virtanen Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 04 Nov 2003 16:02:34 +0200 Lines: 13 Approved: news@gmane.org Message-ID: <3FA7B17A.3080207@tv.debian.net> References: <20031104102952.GC15674@adamantix.org> <20031104123135.GB16244@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067955747 14295 80.91.224.253 (4 Nov 2003 14:22:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 14:22:27 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 15:22:25 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH24f-00041j-00 for ; Tue, 04 Nov 2003 15:22:25 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 8DD671F821; Tue, 4 Nov 2003 08:17:53 -0600 (CST) Old-Return-Path: Original-Received: from kiy.wanderer.org (kiy.wanderer.org [195.218.87.138]) by murphy.debian.org (Postfix) with ESMTP id A9D611F463 for ; Tue, 4 Nov 2003 08:02:38 -0600 (CST) Original-Received: from tv.debian.net (dsl-VI-87.kotikaista.weppi.fi [80.74.198.87]) by kiy.wanderer.org (Postfix) with ESMTP id 5EE75539FB; Tue, 4 Nov 2003 16:00:07 +0200 (EET) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030930 Debian/1.4-5 X-Accept-Language: en Original-To: Peter Busser In-Reply-To: <20031104123135.GB16244@adamantix.org> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155025 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 08:17:53 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44409 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44409 Peter Busser wrote: >>Summary: i can see no significant differences between the paxtest output - >>all the differences seem to be bogus, see the details below. > Fact is: There is a difference in paxtest output between PaX and exec-shield. > And it is not a difference in exec-shield's advantage. Peter, no one contested that there is a difference. Ingo contested the meaningfulnes of that difference. Now, it's your turn trying to explain *why* the difference is meaningful; not just that it exists. HTH, HAND. From nobody Sun Nov 9 12:20:23 2003 Path: main.gmane.org!not-for-mail From: Peter Busser Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 12:39:46 +0100 Lines: 51 Approved: news@gmane.org Message-ID: <20031104113946.GA16244@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067947711 28006 80.91.224.253 (4 Nov 2003 12:08:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 12:08:31 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 13:08:29 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGzz2-000458-00 for ; Tue, 04 Nov 2003 13:08:29 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 11DE61F902; Tue, 4 Nov 2003 05:58:41 -0600 (CST) Old-Return-Path: Original-Received: from mail.adamantix.org (unknown [212.204.216.41]) by murphy.debian.org (Postfix) with ESMTP id F08391F95D for ; Tue, 4 Nov 2003 05:41:18 -0600 (CST) Original-Received: by mail.adamantix.org (Postfix, from userid 1000) id 0497D6B649; Tue, 4 Nov 2003 12:39:47 +0100 (CET) Original-To: debian-devel@lists.debian.org Content-Disposition: inline User-Agent: Mutt/1.3.28i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155012 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 05:58:41 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44396 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44396 Hi! > [NB: When reponsding using the web archives, please get the References > and In-Reply-To: correctly. You may also consider setting MFT:] I can't post from the lists.debian.org site. > On Tue, 04 Nov 2003, Peter Busser wrote: > >> PaX would take much more time so I can't do it. > > > > You cannot do it or you don't want to do it? > Russell has made it adequately clear that he doesn't have the time or > the desire to deal with PaX at this time. As a volunteer, that's > always his prerogative. [As a side note, if you are trying to enlist > volunteers, I strongly suggest not berating other developers while > doing it.[1]] Agreed, Russell is free to do what he wants. However, other Debian developers benefit from having accurate information, to base their opinions on. And so far I have seen statements on PaX that have been anything but accurate. I'm not in fact trying enlist volunteers. I try to offend as many Debian people as possible, so that they choose exec-shield. This to ensure that Adamantix will has an edge in security over Debian in the future. And it seems to be working very well so far. Besides that, I can imagine that gr-security does not work on the current Debian kernels. But really, PaX and gr-security are two completely different things. PaX is related to gr-security in the same way the Linux kernel is related to Debian. It is just a part of it, but the PaX project is independent of gr-security. > > In fact, anyone can do it Russell, I'm pretty sure even you can do > > it: > Why not volunteer to make the .deb, get a sponsor and get it uploaded > then? Good idea! Already did that in fact. So who do I send this new kernel-source .deb to? Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ From nobody Sun Nov 9 12:20:24 2003 Path: main.gmane.org!not-for-mail From: Michael Ablassmeier Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 13:52:12 +0100 Lines: 21 Approved: news@gmane.org Message-ID: <20031104125212.GA34649@jail.schiach.de> References: <20031104113946.GA16244@adamantix.org> Reply-To: abi@grinser.de NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067950620 1678 80.91.224.253 (4 Nov 2003 12:57:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 12:57:00 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 13:56:58 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH0jy-0006lC-00 for ; Tue, 04 Nov 2003 13:56:58 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 54D051F7DA; Tue, 4 Nov 2003 06:53:17 -0600 (CST) Old-Return-Path: Original-Received: from schiach.de (enz.schiach.de [213.239.192.71]) by murphy.debian.org (Postfix) with ESMTP id C6E621F7F5 for ; Tue, 4 Nov 2003 06:52:50 -0600 (CST) Original-Received: by schiach.de (Postfix, from userid 2002) id E1D90210AA; Tue, 4 Nov 2003 13:52:12 +0100 (CET) Original-To: debian-devel@lists.debian.org Mail-Followup-To: Michael Ablassmeier , debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <20031104113946.GA16244@adamantix.org> User-Agent: Mutt/1.4.1i X-Accept-Language: de en Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155017 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 06:53:17 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44401 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44401 On Tue, Nov 04, 2003 at 12:39:46PM +0100, Peter Busser wrote: > > Why not volunteer to make the .deb, get a sponsor and get it uploaded > > then? > > Good idea! Already did that in fact. So who do I send this new kernel-source > .deb to? You can use the mentors service to exchange your packages with your sponsor. All informations how to (d)upload your packages to the Mentors Server are explained on the homepage[0]. After uploading it to the Server you can seek for an sponsor using debian-mentors@lists.debian.org, this one (debian-devel), or the phpBB forum which is also aviable at the mentors homepage. [0] http://mentors.debian.net bye, - michael From nobody Sun Nov 9 12:20:24 2003 Path: main.gmane.org!not-for-mail From: Mario Lang Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 04 Nov 2003 14:21:04 +0100 Lines: 21 Sender: Mario Lang Approved: news@gmane.org Message-ID: <87fzh446db.fsf@lexx.delysid.org> References: <20031104113946.GA16244@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067954366 10748 80.91.224.253 (4 Nov 2003 13:59:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 13:59:26 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 14:59:24 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH1iO-0002Kp-00 for ; Tue, 04 Nov 2003 14:59:24 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 1132E1F4BD; Tue, 4 Nov 2003 07:57:29 -0600 (CST) Old-Return-Path: Original-Received: from lexx.delysid.org (chello080109223066.lancity.graz.surfer.at [80.109.223.66]) by murphy.debian.org (Postfix) with ESMTP id 0D8C01F705 for ; Tue, 4 Nov 2003 07:21:03 -0600 (CST) Original-Received: from mlang by lexx.delysid.org with local (Exim 3.36 #1 (Debian)) id 1AH17I-0000Qo-00; Tue, 04 Nov 2003 14:21:04 +0100 Original-To: Peter Busser In-Reply-To: <20031104113946.GA16244@adamantix.org> (Peter Busser's message of "Tue, 4 Nov 2003 12:39:46 +0100") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155024 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 07:57:29 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44408 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44408 Peter Busser writes: >> On Tue, 04 Nov 2003, Peter Busser wrote: >> > In fact, anyone can do it Russell, I'm pretty sure even you can do >> > it: >> Why not volunteer to make the .deb, get a sponsor and get it uploaded >> then? > > Good idea! Already did that in fact. So who do I send this new kernel-source > .deb to? I sincerely hope that you did not create a prepatched kernel-source package. OTOH, this would explain a lot about your mails on d-d. -- CYa, Mario | Debian Developer | Get my public key via finger mlang@db.debian.org | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 From nobody Sun Nov 9 12:20:24 2003 Path: main.gmane.org!not-for-mail From: Rob Weir Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Wed, 5 Nov 2003 23:03:11 +1100 Lines: 46 Approved: news@gmane.org Message-ID: <20031105120311.GA10853@ooder.ertius.org> References: <20031104113946.GA16244@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" X-Trace: sea.gmane.org 1068035925 30925 80.91.224.253 (5 Nov 2003 12:38:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 12:38:45 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 13:38:42 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHMvq-0003Ny-00 for ; Wed, 05 Nov 2003 13:38:42 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E61F91FA34; Wed, 5 Nov 2003 06:31:37 -0600 (CST) Old-Return-Path: Original-Received: from hesperos.ertius.org (hesperos.realmtech.net [216.17.101.96]) by murphy.debian.org (Postfix) with ESMTP id 6A6651F70C for ; Wed, 5 Nov 2003 06:30:46 -0600 (CST) Original-Received: from hesperos.ertius.org (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 37F333033B for ; Wed, 5 Nov 2003 23:34:24 +1100 (EST) Original-Received: from leserver.ertius.org (203-31-48-58.netspeed.com.au [203.31.48.58]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "leserver.ertius.org", Issuer "Rob Weir" (verified OK)) by hesperos.ertius.org (Postfix) with ESMTP id 8CEAE3033D for ; Wed, 5 Nov 2003 23:33:37 +1100 (EST) Original-Received: from ooder.ertius.org (ooder.ertius.org [192.168.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ooder.ertius.org", Issuer "Rob Weir" (verified OK)) by leserver.ertius.org (Postfix) with ESMTP id 472CD1DB96 for ; Thu, 6 Nov 2003 08:15:05 +1100 (EST) Original-Received: by ooder.ertius.org (Postfix, from userid 1000) id 94F9847E594; Wed, 5 Nov 2003 23:03:11 +1100 (EST) Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <20031104113946.GA16244@adamantix.org> User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155099 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 06:31:37 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44483 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44483 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 04, 2003 at 12:39:46PM +0100, Peter Busser said > > On Tue, 04 Nov 2003, Peter Busser wrote: > > > In fact, anyone can do it Russell, I'm pretty sure even you can do > > > it: > > Why not volunteer to make the .deb, get a sponsor and get it uploaded > > then? >=20 > Good idea! Already did that in fact. So who do I send this new kernel-sou= rce > .deb to? Put it up somewhere and then ask on the debian-mentors (@lists.debian.org) list for a sponsor. I sure hope you mean "...this new kernel-patch .deb...", though, since adding an entirely new kernel source package for a patch that "takes less time to apply the patch to the Debian kernel than the time that is wasted on this discussion" seems silly. --=20 Rob Weir | mlspam@ertius.org | Do I look like I want a= CC? Words of the day: Yukon JFK min= dwar --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qOb+vQ+DhR5zt80RAhMzAKCF9+CrHEwk+/CDKjpsgOVdzlLHrgCfTtHi dngETkVj32pIliMD5skJy5g= =i1dh -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From nobody Sun Nov 9 12:20:25 2003 Path: main.gmane.org!not-for-mail From: spender@grsecurity.net Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 10:56:23 -0500 Lines: 391 Approved: news@gmane.org Message-ID: <20031104155623.GA30743@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067964586 4838 80.91.224.253 (4 Nov 2003 16:49:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 16:49:46 +0000 (UTC) Cc: spender@grsecurity.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 17:49:44 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH4ND-0007nf-00 for ; Tue, 04 Nov 2003 17:49:43 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C10291F457; Tue, 4 Nov 2003 10:43:33 -0600 (CST) Old-Return-Path: Original-Received: from grsecurity.net (grsecurity.net [63.100.47.84]) by murphy.debian.org (Postfix) with ESMTP id 3A1CD1F418 for ; Tue, 4 Nov 2003 10:14:39 -0600 (CST) Original-Received: by grsecurity.net (Postfix, from userid 1000) id 424075B6AD; Tue, 4 Nov 2003 10:56:23 -0500 (EST) Original-To: debian-devel@lists.debian.org Content-Disposition: inline User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155035 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 10:43:33 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44419 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44419 > Also note that I use LSM on all my kernels, so anything that conflicts with > LSM is something that I have no ability to test and therefore no interest in > maintaining. I'm sure I could get PaX working with LSM, but it would take > some work. Anyway I'll look into this matter after I upload an exec-shield > package. I've spared you your precious time and gone ahead and done this for you. Funny thing is that the latest version of LSM for 2.4 is still at 2.4.20. Trying to patch a clean 2.4.22 kernel with this results in rejects in 9 files. Here're the contents of the rejects: *************** *** 329,335 **** }; #define MAY_PTRACE(p) \ - (p==current||(p->p_pptr==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED)) static int mem_open(struct inode* inode, struct file* file) --- 329,335 ---- }; #define MAY_PTRACE(p) \ + (p==current||(p->p_pptr==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED&&security_ops->ptrace(current,p)==0)) static int mem_open(struct inode* inode, struct file* file) *************** *** 1418,1423 **** if (!sb) goto out; } ret = -EINVAL; switch (cmds) { --- 1421,1430 ---- if (!sb) goto out; } + + ret = security_ops->quotactl (cmds, type, id, sb); + if (ret) + goto out; ret = -EINVAL; switch (cmds) { *************** *** 75,86 **** static kmem_cache_t * inode_cachep; - #define alloc_inode() \ - ((struct inode *) kmem_cache_alloc(inode_cachep, SLAB_KERNEL)) static void destroy_inode(struct inode *inode) { if (inode_has_buffers(inode)) BUG(); kmem_cache_free(inode_cachep, (inode)); } --- 76,101 ---- static kmem_cache_t * inode_cachep; + static inline struct inode *alloc_inode(void) + { + struct inode *inode; + + inode = ((struct inode *) kmem_cache_alloc(inode_cachep, SLAB_KERNEL)); + if (!inode) + return NULL; + inode->i_security = NULL; + if (security_ops->inode_alloc_security(inode)) { + kmem_cache_free(inode_cachep, (inode)); + return NULL; + } + return inode; + } + static void destroy_inode(struct inode *inode) { if (inode_has_buffers(inode)) BUG(); + security_ops->inode_free_security(inode); kmem_cache_free(inode_cachep, (inode)); } *************** *** 27,32 **** #include #include #include #include --- 27,33 ---- #include #include #include + #include #include *************** *** 1044,1063 **** asmlinkage long sys_sethostname(char *name, int len) { int errno; if (!capable(CAP_SYS_ADMIN)) return -EPERM; if (len < 0 || len > __NEW_UTS_LEN) return -EINVAL; down_write(&uts_sem); - errno = -EFAULT; - if (!copy_from_user(system_utsname.nodename, name, len)) { - system_utsname.nodename[len] = 0; - errno = 0; - } up_write(&uts_sem); - return errno; } asmlinkage long sys_gethostname(char *name, int len) --- 1043,1067 ---- asmlinkage long sys_sethostname(char *name, int len) { + char nodename[__NEW_UTS_LEN+1]; int errno; if (!capable(CAP_SYS_ADMIN)) return -EPERM; if (len < 0 || len > __NEW_UTS_LEN) return -EINVAL; + if (copy_from_user(nodename, name, len)) + return -EFAULT; + nodename[len] = 0; + + errno = security_ops->sethostname(nodename); + if (errno) + return errno; + down_write(&uts_sem); + memcpy(system_utsname.nodename, nodename, len+1); up_write(&uts_sem); + return 0; } asmlinkage long sys_gethostname(char *name, int len) *************** *** 1083,1101 **** */ asmlinkage long sys_setdomainname(char *name, int len) { int errno; if (!capable(CAP_SYS_ADMIN)) return -EPERM; if (len < 0 || len > __NEW_UTS_LEN) return -EINVAL; down_write(&uts_sem); - errno = -EFAULT; - if (!copy_from_user(system_utsname.domainname, name, len)) { - errno = 0; - system_utsname.domainname[len] = 0; - } up_write(&uts_sem); return errno; } --- 1087,1109 ---- */ asmlinkage long sys_setdomainname(char *name, int len) { + char domainname[__NEW_UTS_LEN+1]; int errno; if (!capable(CAP_SYS_ADMIN)) return -EPERM; if (len < 0 || len > __NEW_UTS_LEN) return -EINVAL; + if (copy_from_user(domainname, name, len)) + return -EFAULT; + domainname[len] = 0; + + errno = security_ops->setdomainname(domainname); + if (errno) + return errno; down_write(&uts_sem); + memcpy(system_utsname.domainname, domainname, len+1); up_write(&uts_sem); return errno; } *************** *** 1177,1191 **** static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) { /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces number of warnings when compiling with -W --ANK */ if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) return -ENOMEM; #ifdef CONFIG_FILTER if (sk->filter) { - int err = 0; struct sk_filter *filter; /* It would be deadlock, if sock_queue_rcv_skb is used --- 1192,1211 ---- static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) { + int err = 0; + /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces number of warnings when compiling with -W --ANK */ if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) return -ENOMEM; + err = security_ops->socket_sock_rcv_skb(sk, skb); + if (err) + return err; + #ifdef CONFIG_FILTER if (sk->filter) { struct sk_filter *filter; /* It would be deadlock, if sock_queue_rcv_skb is used *************** *** 62,67 **** #include #include #include #include #include "util.h" --- 62,68 ---- #include #include #include + #include #include #include "util.h" *************** *** 455,458 **** endmenu source lib/Config.in --- 455,459 ---- endmenu + source security/Config.in source lib/Config.in *************** *** 1,7 **** VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 20 - EXTRAVERSION = KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) --- 1,7 ---- VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 20 + EXTRAVERSION = -lsm1 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) *************** *** 121,131 **** #export RAMDISK = -DRAMDISK=512 - CORE_FILES =kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o NETWORKS =net/network.o LIBS =$(TOPDIR)/lib/lib.a - SUBDIRS =kernel drivers mm fs net ipc lib DRIVERS-n := DRIVERS-y := --- 121,131 ---- #export RAMDISK = -DRAMDISK=512 + CORE_FILES =kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o security/vmlinux-obj.o NETWORKS =net/network.o LIBS =$(TOPDIR)/lib/lib.a + SUBDIRS =kernel drivers mm fs net ipc lib security DRIVERS-n := DRIVERS-y := -------------------------------------------------------------------------- Patching the latest release of PaX onto this kernel results in ONE additional reject (arch/ia64/config.in) : *************** *** 291,293 **** fi endmenu --- 291,322 ---- fi endmenu + + mainmenu_option next_comment + comment 'PaX options' + + bool 'Enforce non-executable pages' CONFIG_PAX_NOEXEC + if [ "$CONFIG_PAX_NOEXEC" = "y" ]; then + bool 'Paging based non-executable pages' CONFIG_PAX_PAGEEXEC + if [ "$CONFIG_PAX_PAGEEXEC" = "y" ]; then + # bool ' Emulate trampolines' CONFIG_PAX_EMUTRAMP + # if [ "$CONFIG_PAX_EMUTRAMP" = "y" ]; then + # bool ' Automatically emulate sigreturn trampolines' CONFIG_PAX_EMUSIGRT + # fi + bool ' Restrict mprotect()' CONFIG_PAX_MPROTECT + if [ "$CONFIG_PAX_MPROTECT" = "y" ]; then + bool ' Disallow ELF text relocations' CONFIG_PAX_NOELFRELOCS + # bool ' Automatically emulate ELF PLT' CONFIG_PAX_EMUPLT + # bool ' Allow ELF ET_EXEC text relocations' CONFIG_PAX_ETEXECRELOCS + fi + fi + fi + bool 'Address Space Layout Randomization' CONFIG_PAX_ASLR + if [ "$CONFIG_PAX_ASLR" = "y" ]; then + bool ' Randomize user stack base' CONFIG_PAX_RANDUSTACK + bool ' Randomize mmap() base' CONFIG_PAX_RANDMMAP + if [ "$CONFIG_PAX_RANDMMAP" = "y" -a "$CONFIG_PAX_PAGEEXEC" = "y" ]; then + bool ' Randomize ET_EXEC base' CONFIG_PAX_RANDEXEC + fi + fi + endmenu Now surely, Russell, a "security expert" such as yourself is capable of copy+pasting that last reject in the file. Doing this took one minute. I would imagine this was much less time than it took for you to write your ignorant mails complaining about things you don't understand or haven't bothered to try yourself. Also, I think both you and Ingo will be interested to see the results of a bugfixed version of paxtest. Are you so certain that Exec-shield stops execution in shared library bss/data? Or did you just say it because that's what a program told you? Do you want to change your answer before it's released? Or can you tell me why Exec-shield will prevent execution in those areas? If you can tell my why, I'll be sure to tell you why it doesn't, and why it's impossible for it to. It's pretty funny that there's a claim that Exec-shield doesn't break binary compatibility, since it seems Redhat "invented" a new binary standard. I don't ever recall any discussion of this "standard" before it was committed. PT_GNU_STACK defines when an application requires an executable stack or not. So I wonder what happens when someone tries to run tuxracer on a system that doesn't use PT_GNU_STACK? Will Exec-shield then break "binary compatibility" without the presence of its self-made "standard"? It's fun to learn new things! -Brad From nobody Sun Nov 9 12:20:25 2003 Path: main.gmane.org!not-for-mail From: Michael Ablassmeier Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 18:00:15 +0100 Lines: 20 Approved: news@gmane.org Message-ID: <20031104170015.GE35690@jail.schiach.de> References: <20031104155623.GA30743@grsecurity.net> Reply-To: abi@grinser.de NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067965401 7089 80.91.224.253 (4 Nov 2003 17:03:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 17:03:21 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 18:03:14 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH4aI-0000PY-00 for ; Tue, 04 Nov 2003 18:03:14 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C78CE1F480; Tue, 4 Nov 2003 11:01:08 -0600 (CST) Old-Return-Path: Original-Received: from schiach.de (enz.schiach.de [213.239.192.71]) by murphy.debian.org (Postfix) with ESMTP id 5871B1F47B for ; Tue, 4 Nov 2003 11:00:53 -0600 (CST) Original-Received: by schiach.de (Postfix, from userid 2002) id E2E77210AF; Tue, 4 Nov 2003 18:00:15 +0100 (CET) Original-To: debian-devel@lists.debian.org Mail-Followup-To: Michael Ablassmeier , debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <20031104155623.GA30743@grsecurity.net> User-Agent: Mutt/1.4.1i X-Accept-Language: de en Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155037 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 11:01:08 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44421 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44421 On Tue, Nov 04, 2003 at 10:56:23AM -0500, spender@grsecurity.net wrote: > Now surely, Russell, a "security expert" such as yourself is capable of > copy+pasting that last reject in the file. Doing this took one minute. > I would imagine this was much less time than it took for you to write > your ignorant mails complaining about things you don't understand or > haven't bothered to try yourself. If you get down and you quarrel everyday, You're saying prayers to the devils, I say. Why not help one another on the way? Make it much easier. > It's fun to learn new things! Yes, it is! bye, - michael From nobody Sun Nov 9 12:20:25 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 18:49:58 +0100 (CET) Lines: 45 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <20031104155623.GA30743@grsecurity.net> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1067968615 15879 80.91.224.253 (4 Nov 2003 17:56:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 17:56:55 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 18:56:52 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH5QC-0004sf-00 for ; Tue, 04 Nov 2003 18:56:52 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 166121F5EB; Tue, 4 Nov 2003 11:50:21 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id C9DE01F3F8 for ; Tue, 4 Nov 2003 11:50:04 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id 2060E48A8A; Tue, 4 Nov 2003 18:50:01 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 6D6891FC2; Tue, 4 Nov 2003 18:50:00 +0100 (CET) Original-To: spender@grsecurity.net In-Reply-To: <20031104155623.GA30743@grsecurity.net> Resent-Message-ID: <5buMYD.A.DSG.cb-p_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155041 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 11:50:21 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44425 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44425 On Tue, 4 Nov 2003 spender@grsecurity.net wrote: > [...] Are you so certain that Exec-shield stops execution in shared > library bss/data? [...] no, it doesnt, this is the main (and pretty much only) substantial difference between exec-shield and PaX. Exec-shield will stop execution in ET_EXEC binary's bss/data but it will not stop code injection into library bss/data. Here is the 'protection matrix' of all the overflowable and shellcodable virtual memory areas: stock exec-shield PaX --------------------------------------------------------------- environment/argv/aux no yes yes stack no yes yes anon mmaps no yes yes malloc() no yes yes binary bss/data no yes yes lib bss/data no no yes > [...] So I wonder what happens when someone tries to run tuxracer on a > system that doesn't use PT_GNU_STACK? Will Exec-shield then break > "binary compatibility" without the presence of its self-made "standard"? what do you mean? tuxracer runs just fine here. If you mean exec-shield=2 then it is 'forcing' exec-shield and is only recommended for testing purposes. Running exec-shield=1 on a system with or without PT_GNU_STACK sections will result in a working system. PT_GNU_STACK itself influences nothing. Note that the Fedora kernel defaults to exec-shield=1. PT_GNU_STACK is a way to _automatically_ tag binaries/libraries whether they need the stack to be executable or not. So instead of putting the burden of 'chpax-ing broken applications' on the administrator or distribution maker (and third party developers, and the scientific community, and ...), this method tracks executability requirements automatically. So you'll get a non-executable stack in like 99% of the cases. It would be great if Debian adopted the PT_GNU_STACK changes too, they can push the concept of non-executable stacks into the mainstream. Ingo From nobody Sun Nov 9 12:20:25 2003 Path: main.gmane.org!not-for-mail From: spender@grsecurity.net Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 13:47:48 -0500 Lines: 76 Approved: news@gmane.org Message-ID: <20031104184748.GA10272@grsecurity.net> References: <20031104155623.GA30743@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067974067 434 80.91.224.253 (4 Nov 2003 19:27:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 19:27:47 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 20:27:45 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH6q9-0003cw-00 for ; Tue, 04 Nov 2003 20:27:45 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 35DC81F9B4; Tue, 4 Nov 2003 13:27:19 -0600 (CST) Old-Return-Path: Original-Received: from grsecurity.net (grsecurity.net [63.100.47.84]) by murphy.debian.org (Postfix) with ESMTP id B59951F5D5 for ; Tue, 4 Nov 2003 13:06:06 -0600 (CST) Original-Received: by grsecurity.net (Postfix, from userid 1000) id 520515B6AD; Tue, 4 Nov 2003 13:47:48 -0500 (EST) Original-To: Ingo Molnar Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155051 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 13:27:19 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44435 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44435 On Tue, Nov 04, 2003 at 06:49:58PM +0100, Ingo Molnar wrote: > > On Tue, 4 Nov 2003 spender@grsecurity.net wrote: > > > [...] Are you so certain that Exec-shield stops execution in shared > > library bss/data? [...] > > no, it doesnt, this is the main (and pretty much only) substantial > difference between exec-shield and PaX. Well that sounds quite a bit different than what you had to say about these yesterday: "these are caught by exec-shield too, and are quite important categories to catch." Clearly both cannot be correct at the same time. > Exec-shield will stop execution in > ET_EXEC binary's bss/data but it will not stop code injection into library > bss/data. Here is the 'protection matrix' of all the overflowable and > shellcodable virtual memory areas: > That's not quite correct. Exec-shield "can" stop, but "will" stop is a completely different matter. I'll let the bugfixed paxtest tell this story, however. > If you mean exec-shield=2 then it is 'forcing' exec-shield and is only > recommended for testing purposes. For the benefit of the readers that might have missed this subtle attempt at diverting the main point of my argument: exec-shield=2 means enabling exec-shield on all binaries but the ones it is disabled for. This would be a secure-by-default design, and yet it's being recommended for "testing purposes" only? Note that PaX enables itself on all binaries by default, and that Ingo here does not argue that exec-shield=2 could result in a non-working system. Basically, his following argument, which I cannot refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES, then it results in a working system. Now, I remember some complaining about having to chpax java if you run it and PaX breaks it. How is that more work than running exec-shield in =1 mode, and having to explicitly enable it on all binaries you think should have protection, since you don't recommend =2 for production machines? Or, through what mechanism have you devised to notify the user when an application he thought was protected by exec-shield decides to mprotect an anonymous mapping rwx, thus making the main executable's bss and data sections executable? Viewing the process' maps file isn't going to tell you what kind of protection the process currently has. How about if someone mprotects a page of the stack rwx? Whoops, entire address space because executable. I'm also curious, given the rest of your model, how the lack of trampoline emulation is a security feature. From your announcement: To provide as good protection as possible, there's no trampoline workaround in the exec-shield code - ie. exec-limit violations in the trampoline case are never let through. Applications that need to rely on gcc trampolines will have to use the per-binary ELF flag to make the stack executable again. This all sounds very contradictory to your point that there's only one substantial difference between PaX and Exec-shield (funny how it was never mentioned that PaX is a true per-page implementation, while yours is much more coarse grained...that sounds pretty substantial too). Though, I don't know what I'm talking about here. Clearly every Debian developer who was kind enough to make useless non-technical posts to this thread know much more about this subject than I do. So please, listen to your in house "security experts" instead of me. They're probably better for a good laugh, anyways. -Brad From nobody Sun Nov 9 12:20:25 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 21:00:36 +0100 (CET) Lines: 114 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <20031104155623.GA30743@grsecurity.net> <20031104184748.GA10272@grsecurity.net> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1067976351 5930 80.91.224.253 (4 Nov 2003 20:05:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 20:05:51 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 21:05:49 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH7Qz-0006Ri-00 for ; Tue, 04 Nov 2003 21:05:49 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id CAACD1F648; Tue, 4 Nov 2003 14:05:22 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id A2F061F41F for ; Tue, 4 Nov 2003 14:05:15 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id DED92488D3; Tue, 4 Nov 2003 21:00:37 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 2E39F1FC2; Tue, 4 Nov 2003 21:00:37 +0100 (CET) Original-To: spender@grsecurity.net In-Reply-To: <20031104184748.GA10272@grsecurity.net> Resent-Message-ID: <34tz9B.A.8LB.CaAq_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155053 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 14:05:22 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44438 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44438 On Tue, 4 Nov 2003 spender@grsecurity.net wrote: > [...] the main point of my argument: exec-shield=2 means enabling > exec-shield on all binaries but the ones it is disabled for. This would > be a secure-by-default design, and yet it's being recommended for > "testing purposes" only? [...] yes. It's a compatible opt-in for something that cannot be enabled for all binaries, instead of an opt-out. You say it's a bug, i say it's a feature. A really bad analogy: it's like spam, you want to opt-in not opt-out ;) > [...] Note that PaX enables itself on all binaries by default, and that > Ingo here does not argue that exec-shield=2 could result in a > non-working system. Basically, his following argument, which I cannot > refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES, > then it results in a working system. my main argument is that on a PT_GNU_STACK-recompiled system, you'll see that the overwhelming majority of binaries and libraries have a non-exec stack almost straight away. With some extra tweaking and patching it's up to 99.9%. [ or you can manually force on the feature for every binary, if you dont have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on a per binary basis, if you want/need to. ] i'm not sure why you are fighting the PT_GNU_STACK concept - it's not connected to exec-shield at all - just take the ELF loader bits from the exec-shield patch and use it in PaX - it will be for the better to get rid of a fair share of chpax use. (Like you changed the library layout in PaX to match that of exec-shield.) if you could get rid of the 1.5 GB VM limitation of PaX and if you could change it to use PT_GNU_STACK to set the process stack's protection bits then i think there's no need for exec-shield - PaX will provide better protection at no cost and no tradeoffs. I did and still do exec-shield to solve a problem. If something else does it better with no tradeoffs then all the better, one less maintainance headache :-) > Now, I remember some complaining about having to chpax java if you run > it and PaX breaks it. How is that more work than running exec-shield in > =1 mode, and having to explicitly enable it on all binaries you think > should have protection, since you don't recommend =2 for production > machines? you dont have to explicitly enable it on all binaries you think should have protection - the compiler will do this just fine via PT_GNU_STACK. It is a property of the binary, not some policy question, whether an application needs an executable stack or not. where does PaX re-enable stack executability if an application dlopen()s a library that needs an executable stack - because eg. it is using gcc trampolines? Can you enable PaX for Mozilla and guarantee that no plugin will ever need an executable stack? java (or any other non-PT_GNU_STACK third party app) will just default to exec-shield-off. > Viewing the process' maps file isn't going to tell you what kind of > protection the process currently has. [...] the maps file will precisely tell you what kind of protection the process currently has - take the highest executable address. I've got a script with which you can continuously monitor the protection status of various apps on the system. Offenders are taken care of :-) > [...] How about if someone mprotects a page of the stack rwx? Whoops, > entire address space because executable. yes. No app currently running on my box does this though. this is one fundamental difference in the approach: instead of breaking apps and then chpax-ing them, exec-shield lets apps tell that they are capable of a non-exec stack. > From your announcement: > > To provide as good protection as possible, there's no trampoline > workaround in the exec-shield code - ie. exec-limit violations in the > trampoline case are never let through. Applications that need to rely on > gcc trampolines will have to use the per-binary ELF flag to make the > stack executable again. this is an old announcement, and says other things too that are not the case anymore. E.g. this area got reworked since then and these (rare but existing) apps/libs are detected automatically via the PT_GNU_STACK mechanism. it's very easy to list the app executability requirements and the current protections in a live system, and it's easy to improve them one by one - while still having a 100% working system. > [...] (funny how it was never mentioned that PaX is a true per-page > implementation, while yours is much more coarse grained...that sounds > pretty substantial too). under the exec-shield VM layout the only real relevance this has is on library bss/data executability, for like 99% (or more) of the apps. But yes, page granularity execution bits are a plus and are available on the platforms of the future. It was not acceptable to limit the VM to 1.5GB on x86. It's a tradeoff. really, if you think granularity is a big issue for everything else but library bss/data then feel free to install Fedora and check out the mappings. It just doesnt happen all that often anymore that an app triggers some really bad protection layout, and if it happens, it's fixable in a nonintrusive way. The important thing is to have protection here and now for 99% of the layouts in a generic distribution. [with the caveat of library bss/data, as you correctly observed.] Ingo From nobody Sun Nov 9 12:20:27 2003 Path: main.gmane.org!not-for-mail From: spender@grsecurity.net Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 17:30:09 -0500 Lines: 106 Approved: news@gmane.org Message-ID: <20031104223009.GA22804@grsecurity.net> References: <20031104155623.GA30743@grsecurity.net> <20031104184748.GA10272@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067987979 27342 80.91.224.253 (4 Nov 2003 23:19:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 23:19:39 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 00:19:37 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHASW-0003Zi-00 for ; Wed, 05 Nov 2003 00:19:36 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 93DBC1F6F4; Tue, 4 Nov 2003 17:05:18 -0600 (CST) Old-Return-Path: Original-Received: from grsecurity.net (grsecurity.net [63.100.47.84]) by murphy.debian.org (Postfix) with ESMTP id E1F5C1F9E8 for ; Tue, 4 Nov 2003 16:48:29 -0600 (CST) Original-Received: by grsecurity.net (Postfix, from userid 1000) id 5EDB95B6AD; Tue, 4 Nov 2003 17:30:09 -0500 (EST) Original-To: Ingo Molnar Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155069 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 17:05:18 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44453 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44453 > yes. It's a compatible opt-in for something that cannot be enabled for all > binaries, instead of an opt-out. You say it's a bug, i say it's a feature. > A really bad analogy: it's like spam, you want to opt-in not opt-out ;) That is indeed a really bad analogy. Security shouldn't be as unwanted as spam. > > > [...] Note that PaX enables itself on all binaries by default, and that > > Ingo here does not argue that exec-shield=2 could result in a > > non-working system. Basically, his following argument, which I cannot > > refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES, > > then it results in a working system. > > my main argument is that on a PT_GNU_STACK-recompiled system, you'll see > that the overwhelming majority of binaries and libraries have a non-exec > stack almost straight away. With some extra tweaking and patching it's up > to 99.9%. > > [ or you can manually force on the feature for every binary, if you dont > have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on > a per binary basis, if you want/need to. ] > > i'm not sure why you are fighting the PT_GNU_STACK concept - it's not > connected to exec-shield at all - just take the ELF loader bits from the > exec-shield patch and use it in PaX - it will be for the better to get rid > of a fair share of chpax use. (Like you changed the library layout in PaX > to match that of exec-shield.) > > if you could get rid of the 1.5 GB VM limitation of PaX and if you could > change it to use PT_GNU_STACK to set the process stack's protection bits > then i think there's no need for exec-shield - PaX will provide better > protection at no cost and no tradeoffs. I did and still do exec-shield to > solve a problem. If something else does it better with no tradeoffs then > all the better, one less maintainance headache :-) > > > Now, I remember some complaining about having to chpax java if you run > > it and PaX breaks it. How is that more work than running exec-shield in > > =1 mode, and having to explicitly enable it on all binaries you think > > should have protection, since you don't recommend =2 for production > > machines? > > you dont have to explicitly enable it on all binaries you think should > have protection - the compiler will do this just fine via PT_GNU_STACK. It > is a property of the binary, not some policy question, whether an > application needs an executable stack or not. > > where does PaX re-enable stack executability if an application dlopen()s a > library that needs an executable stack - because eg. it is using gcc > trampolines? Can you enable PaX for Mozilla and guarantee that no plugin > will ever need an executable stack? If a library uses trampolines, PaX doesn't need to enable stack executability because it has trampoline emulation. I enable PaX on mozilla and use several plugins including flash with no problems. > java (or any other non-PT_GNU_STACK third party app) will just default to > exec-shield-off. > > > Viewing the process' maps file isn't going to tell you what kind of > > protection the process currently has. [...] Sorry, I should have said "what protection the process had a millisecond before you decided to check its maps file" It's this kind of "quantum security" (while you don't observe it, it could be doing what you want or nothing at all) that I wouldn't want as an administrator. If a binary decides to create a mapping with some bad protections, in PaX, the administrator would be notified. In Exec-shield, this kind of behavior will affect the executability of sections of the address space that were previously non-executable and the administrator might never know, even if he had the same script as you checking processes on the system. > this is an old announcement, and says other things too that are not the > case anymore. E.g. this area got reworked since then and these (rare but > existing) apps/libs are detected automatically via the PT_GNU_STACK > mechanism. but is it not still true that you don't have trampoline emulation: if an application uses trampolines the solution in exec-shield is to make the entire stack executable? > really, if you think granularity is a big issue for everything else but > library bss/data then feel free to install Fedora and check out the > mappings. It just doesnt happen all that often anymore that an app > triggers some really bad protection layout, and if it happens, it's > fixable in a nonintrusive way. The important thing is to have protection > here and now for 99% of the layouts in a generic distribution. [with the > caveat of library bss/data, as you correctly observed.] I'm making a big issue of the granularity because you make a big issue of the 1.5GB limit. While granularity in your case actually is an issue for all exec-shield apps, the fact is I've received no reports of anyone running into address space limits with PaX. So I'll agree that the granularity in cases other than libraries isn't a huge issue, and since you talk about generic distributions, you should also be reasonable enough to accept that for 99% of users the address space limitation is not an issue. grsecurity is used on hundreds of thousands of machines. I would imagine most of them are using PaX. If you think that the address space limitation is an issue for any more than 1% of users (and it's not even a big issue, you can leave on just randomization if you want, or use PAGEEXEC if you can stand the performance hit), then back it up with some numbers of first-hand or second-hand reports. -Brad From nobody Sun Nov 9 12:20:27 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 21:23:58 +0100 (CET) Lines: 19 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <20031104155623.GA30743@grsecurity.net> <20031104184748.GA10272@grsecurity.net> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1067979122 12900 80.91.224.253 (4 Nov 2003 20:52:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 20:52:02 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 21:51:59 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH89f-0001Jv-00 for ; Tue, 04 Nov 2003 21:51:59 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 01A7A1F54B; Tue, 4 Nov 2003 14:29:14 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id A25791F5A3 for ; Tue, 4 Nov 2003 14:28:54 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id A20434A79C; Tue, 4 Nov 2003 21:23:57 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 4D4011FC2; Tue, 4 Nov 2003 21:23:57 +0100 (CET) Original-To: spender@grsecurity.net In-Reply-To: <20031104184748.GA10272@grsecurity.net> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155057 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 14:29:14 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44441 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44441 On Tue, 4 Nov 2003 spender@grsecurity.net wrote: > [...] Exec-shield "can" stop, but "will" stop is a completely different > matter. I'll let the bugfixed paxtest tell this story, however. i am 100% sure that by taking the range-property of exec-shield into account you can construct 'bugfixed' mapping scenarios where exec-shield will be 'Vulnerable' for each test you can construct. If you do that you might as well rename 'pax-test' to 'pax-is-best' ;-) my argument is that for common apps here and now running on my system the layout is good enough for exec-shield to be quite close to that of PaX. (It wont be as complete as PaX though, notably the library bss/data areas wont be protected.) Ingo From nobody Sun Nov 9 12:20:27 2003 Path: main.gmane.org!not-for-mail From: Josselin Mouette Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 04 Nov 2003 19:51:52 +0100 Lines: 38 Sender: Josselin Mouette Approved: news@gmane.org Message-ID: <1067971911.28824.21.camel@arrakis.localnet> References: <20031104155623.GA30743@grsecurity.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-i15UEroX9Nn+LYL3QiGm" X-Trace: sea.gmane.org 1067973126 29329 80.91.224.253 (4 Nov 2003 19:12:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 19:12:06 +0000 (UTC) Cc: Debian development list Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 20:12:00 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH6at-0002Qm-00 for ; Tue, 04 Nov 2003 20:12:00 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id A25721F9AC; Tue, 4 Nov 2003 13:10:44 -0600 (CST) Old-Return-Path: Original-Received: from arrakis.localnet (tc2.perso.ens-lyon.org [62.212.101.78]) by murphy.debian.org (Postfix) with ESMTP id 1F1EA1F602 for ; Tue, 4 Nov 2003 12:51:57 -0600 (CST) Original-Received: from joss by arrakis.localnet with local (Exim 4.24) id 1AH6HQ-0006qw-E4; Tue, 04 Nov 2003 19:51:52 +0100 Original-To: spender@grsecurity.net In-Reply-To: <20031104155623.GA30743@grsecurity.net> X-Mailer: Ximian Evolution 1.4.5 Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155047 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 13:10:44 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44431 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44431 --=-i15UEroX9Nn+LYL3QiGm Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Le mar 04/11/2003 =E0 16:56, spender@grsecurity.net a =E9crit : > Also, I think both you and Ingo will be interested to see the results of=20 > a bugfixed version of paxtest. Are you so certain that Exec-shield=20 > stops execution in shared library bss/data? Or did you just say it=20 > because that's what a program told you? Do you want to change your=20 > answer before it's released? Or can you tell me why Exec-shield will=20 > prevent execution in those areas? If you can tell my why, I'll be sure=20 > to tell you why it doesn't, and why it's impossible for it to. Give us facts. Are you advertising the latest Windows 2012 server software before it is written, or discussing about computer security? --=20 .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom --=-i15UEroX9Nn+LYL3QiGm Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/p/VHrSla4ddfhTMRAipgAJ9+p/9x6Lz9yXaoLW9qn9PbA3fulACeMheb 8tX2V1ukeyYcwSVeS/Ps8+4= =DxII -----END PGP SIGNATURE----- --=-i15UEroX9Nn+LYL3QiGm-- From nobody Sun Nov 9 12:20:27 2003 Path: main.gmane.org!not-for-mail From: viro@parcelfarce.linux.theplanet.co.uk Newsgroups: gmane.linux.debian.devel.general Subject: Re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 19:18:45 +0000 Lines: 19 Sender: Approved: news@gmane.org Message-ID: <20031104191845.GL7665@parcelfarce.linux.theplanet.co.uk> References: <20031104155623.GA30743@grsecurity.net> <1067971911.28824.21.camel@arrakis.localnet> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1067973674 30744 80.91.224.253 (4 Nov 2003 19:21:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 19:21:14 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 20:21:11 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH6jm-00038G-00 for ; Tue, 04 Nov 2003 20:21:10 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 559C21F984; Tue, 4 Nov 2003 13:19:01 -0600 (CST) Old-Return-Path: Original-Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by murphy.debian.org (Postfix) with ESMTP id 904E41F585 for ; Tue, 4 Nov 2003 13:18:46 -0600 (CST) Original-Received: from viro by www.linux.org.uk with local (Exim 4.22) id 1AH6hR-0006p7-QD for debian-devel@lists.debian.org; Tue, 04 Nov 2003 19:18:45 +0000 Original-To: Debian development list Content-Disposition: inline In-Reply-To: <1067971911.28824.21.camel@arrakis.localnet> User-Agent: Mutt/1.4.1i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155049 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 13:19:01 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44433 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44433 On Tue, Nov 04, 2003 at 07:51:52PM +0100, Josselin Mouette wrote: > Le mar 04/11/2003 à 16:56, spender@grsecurity.net a écrit : > > Also, I think both you and Ingo will be interested to see the results of > > a bugfixed version of paxtest. Are you so certain that Exec-shield > > stops execution in shared library bss/data? Or did you just say it > > because that's what a program told you? Do you want to change your > > answer before it's released? Or can you tell me why Exec-shield will > > prevent execution in those areas? If you can tell my why, I'll be sure > > to tell you why it doesn't, and why it's impossible for it to. > > Give us facts. Are you advertising the latest Windows 2012 server > software before it is written, or discussing about computer security? Nah, he just tries to imitate Theo. Unfortunately, he misses some elements - clue, taste and understanding of the difference between arguments and handwaving. Working in that area can make one an asshole; however, being an asshole does not qualify for such work... From nobody Sun Nov 9 12:20:27 2003 Path: main.gmane.org!not-for-mail From: Andrew Saunders Newsgroups: gmane.linux.debian.devel.general Subject: re: Grsec/PaX and Exec-shield Date: Tue, 4 Nov 2003 19:56:38 +0000 Lines: 38 Approved: news@gmane.org Message-ID: <20031104195638.39d6041a.syntaxis@gmx.co.uk> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067978460 11229 80.91.224.253 (4 Nov 2003 20:41:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 20:41:00 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 21:40:58 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH7yz-0000Wi-00 for ; Tue, 04 Nov 2003 21:40:58 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 8B6B21F904; Tue, 4 Nov 2003 14:14:11 -0600 (CST) Old-Return-Path: Original-Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by murphy.debian.org (Postfix) with SMTP id B1F851F61D for ; Tue, 4 Nov 2003 13:53:38 -0600 (CST) Original-Received: (qmail 29537 invoked by uid 65534); 4 Nov 2003 19:53:36 -0000 Original-Received: from adsl-190-101.iomart.com (EHLO Torgo) (212.38.190.101) by mail.gmx.net (mp004) with SMTP; 04 Nov 2003 20:53:36 +0100 X-Authenticated: #12104688 Original-To: debian-devel@lists.debian.org X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155055 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 14:14:11 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44439 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44439 On Tue 4 November, spender wrote: > I've spared you your precious time and gone ahead and done this for > you. You might have a better reception if you dropped the attitude. Anyone reading the thread will quickly form the opinion that maintaining PaX within Debian would likely require frequent interaction with people like yourself{1}, Tiago Assumpcao{2} and Peter Busser{3}. On the other hand, maintaining exec-shield would involve collaborating with people like Ingo Molnar. From reading your respective posts, I know which I'd prefer... {1} http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00076.html - Arrogant arsehole. Professes not to care if users get rooted, and would apparently withhold security vulnerabilities he discovers in competing projects in order to further the ends of the one he himself prefers. {2} http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00090.html - Paranoid loon who believes the exec-shield ITP is part of some sinister RedHat conspiracy to take away our freedoms. {3} http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00158.html - Wants to ensure that Adamantix will have an edge in security over Debian in the future. Claims he "would very much like to see that this project [Adamantix] serves no purpose anymore, because some or all of its ideas ended up in other (more mainstream) distributions" (http://www.adamantix.org/motivation.html), but started the distro before even looking into the possibility of working within Debian. Later opted *not* to become a Debian subproject when approached by the DPL. Yet still has the audacity to berate others for not doing enough to get PaX into Debian! From nobody Sun Nov 9 12:20:27 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Exec-Shield vs. PaX Date: Tue, 04 Nov 2003 22:12:04 +0100 Lines: 232 Approved: news@gmane.org Message-ID: <3FA82434.17565.5937549@localhost> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1067982693 22778 80.91.224.253 (4 Nov 2003 21:51:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 21:51:33 +0000 (UTC) Cc: spender@grsecurity.net, Peter Busser Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Tue Nov 04 22:51:30 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AH95G-0005xr-00 for ; Tue, 04 Nov 2003 22:51:30 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 8B48D1F9F6; Tue, 4 Nov 2003 15:30:20 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0604.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id 4B4261F9AD for ; Tue, 4 Nov 2003 15:12:26 -0600 (CST) Original-Received: from angel (APastourelles-107-1-17-186.w81-48.abo.wanadoo.fr [81.48.127.186]) by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 9978C28005DA; Tue, 4 Nov 2003 22:12:24 +0100 (CET) Original-To: debian-devel@lists.debian.org Priority: normal X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155060 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 15:30:20 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44445 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44445 since a few points have been made regarding $subject, let me clear up a few of them: 1. 'It seems that exec-shield does 99% of what PaX does' i don't know the origin of that number above, for now i'll just stick to the facts i know: - PaX implements perfect non-executable pages on amd64, i386, ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has some imitation of it only on i386 (it's not true per-page). - PaX implements a concept about how runtime code generation should be done, there's nothing similar in Exec-Shield, and it seems that Ingo does not even understand why this is important (for Ingo: please read and understand [1] before you call something bogus, see below for more). - PaX implements best-effort randomization of the entire address space, Exec-Shield does it too but at a higher code complexity and a lower entropy rate while having a worse effect on the kernel entropy pool. 2. paxtest 'proofs' i saw several people point to paxtest results to 'prove' how good Exec-Shield it is. it is not. first, Exec-Shield has a fundamental design problem stemming from the lack of understanding or design on Ingo's part (what i call MPROTECT in PaX). you'll really have to read the PaX design docs to understand its role in the grand scheme of things (see below for a bit more). second, paxtest had some bugs which Exec-Shield exposed and made Exec-Shield appear better than it is. i've fixed them here and expect to release 0.9.5 today or so. the results now look like: PaXtest - Copyright(c) 2003 by Peter Busser Released under the GNU Public Licence version 2 or later It may take a while for the tests to complete Test results: PaXtest - Copyright(c) 2003 by Peter Busser Released under the GNU Public Licence version 2 or later Executable anonymous mapping : Vulnerable Executable bss : Vulnerable Executable data : Vulnerable Executable heap : Vulnerable Executable stack : Vulnerable the above changes are the result of Ingo's approach to create non-executable memory on i386, they're not per page as a simple mprotect on the top of the stack shows. before i get accused of specifically rigging the tests, i'll tell you that running multithreaded apps would have almost the same effect (only the main stack would stay non-exec under Exec-Shield). needless to say, PaX passes all the above as before. Executable anonymous mapping (mprotect) : Vulnerable Executable bss (mprotect) : Vulnerable Executable data (mprotect) : Vulnerable Executable heap (mprotect) : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Executable stack (mprotect) : Vulnerable Anonymous mapping randomisation test : 8 bits (guessed) Heap randomisation test (ET_EXEC) : 13 bits (guessed) Heap randomisation test (ET_DYN) : 13 bits (guessed) Main executable randomisation (ET_EXEC) : No randomisation Main executable randomisation (ET_DYN) : 12 bits (guessed) Shared library randomisation test : 12 bits (guessed) Stack randomisation test (SEGMEXEC) : 17 bits (guessed) Stack randomisation test (PAGEEXEC) : 17 bits (guessed) Return to function (strcpy) : Vulnerable Return to function (strcpy, RANDEXEC) : Vulnerable Return to function (memcpy) : Vulnerable Return to function (memcpy, RANDEXEC) : Vulnerable Executable shared library bss : Vulnerable Executable shared library data : Vulnerable these two had bugs in them (they were trying to execute code from the wrong location). i find it somewhat funny that the Exec-Shield proponents (including Ingo himself) have used the previous false results as a justification for their claims. apparently none of you understood what the tests and Exec- Shield did, otherwise you would have known that Exec-Shield cannot possibly pass these tests due to its design (or at least not without going down the OpenBSD road). Writable text segments : Vulnerable 3. MPROTECT is bogus it is not. Ingo says so because he did not understand how PaX works. the short story (there's no substitute to reading the docs!) is that in PaX we want to handle the problems posed by memory corruption bugs. all such bugs. the approach chosen in PaX is based on preventing exploit techniques from working (vs. preventing specific bug situations from occuring, at least for now, efficient full runtime bounds checking will have to wait a bit). in the docs you will find a classificaiton of exploit techniques: (1) introduce/execute arbitrary code (2) execute existing code out of original program order (3) execute existing code in original program order with arbitrary data every possible exploit technique against memory corruption bugs belongs to one of the above (note that it is a classification of exploit techniques, not bugs, that is, a given technique can be used against different bugs and a given bug can be exploited by more than one technique). the idea in PaX is that we try to prevent entire classes of exploit techniques from working, starting with the easy ones and going up to the hard problems. in the present situation (1) has been dealt with, (2) is in the works, and (3) is somewhere in the future (pending some research). dispite Ingo's claim, restricting page protection transitions on memory pages (which is what the mprotect() restrictions do) is mandatory for our purposes, far from being bogus. without it, it remains possible to introduce/execute new code into a process. with MPROTECT and the ACL system (or a read-only chroot) to prevent arbitrary file mappings and/or creation you can prevent attack method (1), guaranteed. the fact that PaX does not contain the ACL part is the simple consequence of its being used by different projects who want to do it their way, i explicitly chose not to stand in there (for the same reason PaX itself does not prevent information leaking in /proc, that's up to the patch integrators). Ingo also implied that executing an in-memory shell script via system() does (1). it does not, it does (2). think about it, (1) is about executable machine code, a shell script is not machine code. Ingo also confuses MPROTECT with mprotect() restrictions, the former is much more than the latter, it's about separating the writable pages from executable ones for the purposes of preventing (1), something that Exec-Shield doesn't (cannot) do. Ingo also argues about non-completness... in the main doc there's an explicit paragraph for people like him, please read it again. it will explain to you why you cannot judge a building block on its own, only together with others. the combined effect is much more than what the individual pieces are capable of. PaX is not a finished project, there are several pieces of the puzzle yet to be written. 4. PaX breaks apps, specs, whatnot i chose to enable most of PaX by default (while allowing as many apps to run as possible, e.g., that's why ELF text relocs are allowed by default). since PaX explicitly wants to prevent runtime code generation, obviously apps that want to do it will no longer work. there are two categories of such apps and two ways to fix them. - apps that don't really need to generate code runtime but still do it for whatever reason: they are buggy and must be fixed at the source level. one prime example is the module loader code in XFree86 which assumes that malloc()'ed memory was executable whereas it was not (run strace on any app and you'll see how glibc uses mmap() to request memory). another good example is the various .plt stubs that are runtime generated on many risc archs, for now i added emulation to them, but eventually they'd better be redesigned a la i386. - apps that by their nature want to generate code runtime (e.g., java). they're broken for good which many people noticed by now. that's good, that was my purpose because i wanted to draw attention to the fact that runtime code generation is an important privilege that should be carefully managed (as it happens to be also one of the exploit techniques). of course if you don't agree with my exploit technique classification and the general solution approach i took with PaX, then there's nothing to discuss and you can stop reading this ;-). for those who are interested in solving this problem, please read my proposal in mprotect.txt (available at [1]). about PaX breaking specs: i urge Ingo and others saying this to point me to the precise location in SUSv3 or POSIX 1003.1-2001 that PaX conflicts with. for all i know, none of these standards give ANY guarantees about the ability to generate code at runtime. and rightly so, just think of non-coherent cache systems, you need explicit userland (or kernel assisted, not sure how all such systems solve it) flush interfaces, nothing like that is in the standards (msync() is for something else, nor is it used by any code i know that generates code at runtime, so they'd be non-compliant even if msync() was meant for this purpose). about SEGMEXEC and the 1.5GB limit: yes, it's true, yes, it could be changed (if one can live with a more limited range for executable mappings), yes, it would need some userland tagging, yes, i have ideas for it, no, it's got nothing to do with PT_GNU_STACK. the longer story is that the majority of users don't need to care about this address space limit, it's mainly databases and some scientific applications that run into. mind you, they already had this problem before when people were using 1-2 GB userlands (which back then was the way to allow the kernel to use more than 1 GB RAM, and even these days it's the only way to go if you don't want HIGHMEM). as for userland tagging: i'd like to have much more control over what userland can request from the kernel than what PT_GNU_STACK allows. for one, requesting executable stacks is irrelevant, it should be about requesting permission to generate code at runtime (or just use my proposed mmap() interface changes), request randomization, etc. i'd also like to have control over the placement of the stack and the userland address space size in the future. for now chpax is the quick & dirty solution for tagging, although users of complete systems with ACLs (grsec or RSBAC in Adamantix) can control the PaX flags via ACLs, no need for binary modifications. mind you, it's somewhat misleading to state that PT_GNU_STACK is a better solution than chpax, after all, someone HAS to decide whether a given module needs it or not (before someone points it out, trampolines are only a small and least important part of the problem), the toolchain cannot automatically determine it, so it needs the exact same manual work as chpax. i'm sure i left questions unanswered, feel free to ask here or in private. [1] http://pageexec.virtualave.net/docs/ PS: please CC on responses. From nobody Sun Nov 9 12:20:28 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 00:58:30 +0100 (CET) Lines: 218 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA82434.17565.5937549@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1067990482 32297 80.91.224.253 (5 Nov 2003 00:01:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 00:01:22 +0000 (UTC) Cc: debian-devel@lists.debian.org, spender@grsecurity.net, Peter Busser Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 01:01:19 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHB6t-00061n-00 for ; Wed, 05 Nov 2003 01:01:19 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 9CCE31F400; Tue, 4 Nov 2003 17:59:50 -0600 (CST) Old-Return-Path: Original-Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by murphy.debian.org (Postfix) with ESMTP id B77D11F3C7 for ; Tue, 4 Nov 2003 17:59:31 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id 272B4475B1; Wed, 5 Nov 2003 00:58:31 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 73B451FC2; Wed, 5 Nov 2003 00:58:30 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FA82434.17565.5937549@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155073 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 17:59:50 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44457 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44457 On Tue, 4 Nov 2003 pageexec@freemail.hu wrote: > since a few points have been made regarding $subject, let me clear > up a few of them: > > 1. 'It seems that exec-shield does 99% of what PaX does' this is not the case and i'm not claiming it. If you feel attacked, please dont - i'll stipulate that PaX gives better security than exec-shield, ok? > i don't know the origin of that number above, for now i'll just > stick to the facts i know: > > - PaX implements perfect non-executable pages on amd64, i386, > ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has > some imitation of it only on i386 (it's not true per-page). non-executable pages on anything else but i386 is a triviality, as the hardware and the kernel supports it. There's virtually nothing that PaX or exec-shield has to add to enable them - they are there. [there's the minor issue of the process stack's protection bits.] > - PaX implements best-effort randomization of the entire > address space, Exec-Shield does it too but at a higher > code complexity and a lower entropy rate while having > a worse effect on the kernel entropy pool. lets also point out that exec-shield offers relative randomization of DSOs to each other, while PaX only randomizes a single base of the DSOs, their relative addresses remain constant. This way the randomization bits of exec-shield add up for brute-force attacks. Lets add it that if a limited exploit can be turned into an information leak then relative randomization does not help - but it does help if the first exploit itself needs precise addresses from multiple DSOs. (I agree that exec-shield drains the entropy pool more, i've got this on my TODO.) > second, paxtest had some bugs which Exec-Shield exposed and made > Exec-Shield appear better than it is. i've fixed them here and > expect to release 0.9.5 today or so. the results now look like: ( how fair that you give me a chance to run it ... not. ) > 3. MPROTECT is bogus > > it is not. Ingo says so because he did not understand how > PaX works. [...] [ ... to 100% prevent: ] > (1) introduce/execute arbitrary code > (2) execute existing code out of original program order > (3) execute existing code in original program order with arbitrary data no. No offense meant, but i say so because right now i dont see the way to have a generic and usable Linux system with all the restrictions you are talking about. If you complete your project and everything works and it's still the same live, flexible and kicking Linux system that we all know and love then i was clearly wrong. Right now it seems to be heading more in the direction of a prison - but this is just my judgement. In any case, i did not want to add any of that to exec-shield. I'll leave the prison guard work to selinux. you do realise that most of those 'exploit techniques' overlap with some programming concepts, and you think that those concepts are flawed by design and should be eliminated - i dont agree with this characterisation. denying executability of non-executable memory is a fair game - well specified and a clear-cut goal. Restricting an OS to do what is arguably a fair thing to do in a number of cases did not sound so clear-cut to me - end of story. You might still be right in the long run, but it wasnt obviously right at first sight, and was not complete either so it had limited value at this stage. > 4. PaX breaks apps, specs, whatnot > - apps that by their nature want to generate code runtime (e.g., > java). they're broken for good which many people noticed by now. > that's good, that was my purpose because i wanted to draw > attention to the fact that runtime code generation is an > important privilege that should be carefully managed (as it > happens to be also one of the exploit techniques). [...] i think here we are in a fundamental disagreement. To take it to the extreme, being able to 'generate code' [ie. allow an application to write code, etc.] is one of the fundamental properties of any Linux user account, and hopefully remains so in the future. If you take that 'privilege' away you'll take away what drives Linux forward - a constantly growing pool of programmers. I dont want good security to rely on the system's insistence to remove the ability to generate code from as many codepaths as possible. There's got to be another way to secure those damn apps ... the price you are willing to pay is i believe way too high. i find your approach interesting nevertheless, and i wish you good luck in bringing it to completion. > about PaX breaking specs: i urge Ingo and others saying this to > point me to the precise location in SUSv3 or POSIX 1003.1-2001 > that PaX conflicts with. [...] many areas of PaX conflict with one of the most basic rule of Linux: http://lwn.net/Articles/32980/ [ that i was part of that discussion is only an annoying accident, ending up in an API/ABI discussion again was unintended. ] > about SEGMEXEC and the 1.5GB limit: yes, it's true, yes, it could > be changed (if one can live with a more limited range for executable > mappings), [...] i'm not sure it's acceptable to put _any_ restriction on the layout of the user VM. The rule exec-shield follows is this: whenever the kernel gets a chance to chose it will group mappings smartly, but it will follow requests for executability no matter what. So while this doesnt _force_ good protection, for most apps it provides a pretty acceptable layout. i guess this is a hard-to-solve philosophy difference again. > [...] yes, it would need some userland tagging, yes, i have > ideas for it, no, it's got nothing to do with PT_GNU_STACK. the > longer story is that the majority of users don't need to care about > this address space limit, it's mainly databases and some scientific > applications that run into. mind you, they already had this problem > before when people were using 1-2 GB userlands (which back then > was the way to allow the kernel to use more than 1 GB RAM, and even > these days it's the only way to go if you don't want HIGHMEM). a fair number of users got real happy when we extended the x86 user VM from 3GB to 4GB. Going from 3 GB to 1.5 GB is really not an option i'm afraid. It's also not an option to say that "your app is secure only as long as it fits into 1.5 GB". It also not an option to say "this box is pretty secure, except for your huge database server". and it's not an issue on all the sane architectures, fortunately. So i think having the non-exact protection method of exec-shield will slowly be obsoleted by ia64/amd64 systems anyway. But i'd hate to lose users to Windows just because distros only support 1.5GB of VM. > as for userland tagging: i'd like to have much more control over > what userland can request from the kernel than what PT_GNU_STACK > allows. [...] agreed. But the process stack is arguably a special thing so PT_GNU_STACK isnt incorrect per se. But we'd like to know and say more, i agree fully. > [...] for one, requesting executable stacks is irrelevant, it > should be about requesting permission to generate code at runtime > (or just use my proposed mmap() interface changes), request > randomization, etc. [...] i really dont think we can realistically isolate the code generation capability and still have a nice and flexible system. I dont see anything wrong in apps executing scripts. Or apps writing scripts and executing them. Or apps doing JIT stuff, or just doing some quick runtime fixup. It's quite widely done and it would not be Linux anymore if we try to exterminate or second-class such techniques. And it's even more common in the Windows world, and i really hope those Windows apps continue to come over to Linuxland. randomization is something that is still open. How we solved it in exec-shield is via personalities: it's something that can be set runtime, is inherited across fork() and exec(). If you do "i386 gdb ./a.out" under exec-shield then you'll get a non-randomized ordinary VM layout with static predictable addresses. I dont think this should be tagged via the binary itself - that is too inflexible. There's already one 'VM size bit' in the personality mask in the upstream 2.6 kernel: the 3GB flag for amd64. > [...] i'd also like to have control over the placement of the stack > [...] this wouldnt be too hard, but on x86 it's not a good idea i think. But we can definitely do it on 64-bit platforms, where there's much less danger of vmas crossing each other. as you might have noticed, in recent 2.6.0-test kernels there's already one mprotect() extension that we added to support non-executable stacks: the addition of PROT_GROWSDOWN and PROT_GROWSUP. This new syscall variant enables the dynamic linker to change the process stack's permission without having to know the precise edge of the stack. So the direction is definitely towards having a more flexible layout for processes. > [...] and the userland address space size in > the future. for now chpax is the quick & dirty solution for > tagging, although users of complete systems with ACLs (grsec > or RSBAC in Adamantix) can control the PaX flags via ACLs, > no need for binary modifications. mind you, it's somewhat > misleading to state that PT_GNU_STACK is a better solution > than chpax, after all, someone HAS to decide whether a given > module needs it or not (before someone points it out, trampolines > are only a small and least important part of the problem), the > toolchain cannot automatically determine it, so it needs the > exact same manual work as chpax. no, this is not how PT_GNU_STACK works. PT_GNU_STACK not only detects trampolines, but all those techniques that _might_ point in the direction of process-stack executability. Such as the use of inline assembly. So the toolchain pessimistically turns on executability and guarantees that _if_ the object is marked non-executable, that it certainly needs no executable stack. even the above conservative scheme gave a very high coverage rates, with just a couple of (well below 10% of all) important apps/libs falling out of the nonexecutability umbrella. To solve these cases, application writers/packagers can further improve the accuracy of this scheme by declaring said pieces of code as permitting non-executable, but it's the right place and the best way to document it: in the source. It cannot get lost, it will be updated when the code is changed, etc. Tags tend to get lost, or tend to get incorrect over time. this approach saved tons of work and the system was fully usable all along. Ingo From nobody Sun Nov 9 12:20:31 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 02:49:39 +0100 (CET) Lines: 53 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA82434.17565.5937549@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1067997013 12969 80.91.224.253 (5 Nov 2003 01:50:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 01:50:13 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 02:50:11 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHCoF-0002ic-00 for ; Wed, 05 Nov 2003 02:50:11 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C77ED1F9E6; Tue, 4 Nov 2003 19:49:49 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id 288071F3FC for ; Tue, 4 Nov 2003 19:49:44 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id 540BA48FDB; Wed, 5 Nov 2003 02:49:43 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id EEBCF1FC2; Wed, 5 Nov 2003 02:49:42 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FA82434.17565.5937549@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155081 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Tue, 4 Nov 2003 19:49:49 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44465 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44465 On Tue, 4 Nov 2003 pageexec@freemail.hu wrote: > second, paxtest had some bugs which Exec-Shield exposed and made > Exec-Shield appear better than it is. i've fixed them here and > expect to release 0.9.5 today or so. the results now look like: i downloaded the new 0.9.5 paxtest package and amongst other changes it has the following oneliner change: --- paxtest-0.9.4/body.c +++ paxtest-0.9.5/body.c @@ -29,6 +29,7 @@ fflush( stdout ); if( fork() == 0 ) { + do_mprotect((unsigned long)argv & ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC); doit(); } else { wait( &status ); this intentionally calls mprotect(PROT_EXEC) for the highest possible address one can think of. This call has no useful purpose at all. In other words, this is a specific, underhand cheat to trigger 'Vulnerable' messages for all items when running paxtest on exec-shield kernels. Bravo! frankly, i've never experienced anything like this in my many years in the Linux world. You so far gave the impression of a reasonable and balanced person but this is as low as it gets. Shame on you. here are the paxtest-0.9.5 results with that single purpose-less line removed, for the categories that matter to me: Executable anonymous mapping : Killed Executable bss : Killed Executable data : Killed Executable heap : Killed Executable stack : Killed Anonymous mapping randomisation test : 8 bits (guessed) Heap randomisation test (ET_EXEC) : 13 bits (guessed) Heap randomisation test (ET_DYN) : 13 bits (guessed) Main executable randomisation (ET_EXEC) : No randomisation Main executable randomisation (ET_DYN) : 12 bits (guessed) Shared library randomisation test : 12 bits (guessed) Stack randomisation test (SEGMEXEC) : 17 bits (guessed) Stack randomisation test (PAGEEXEC) : 17 bits (guessed) Executable shared library bss : Vulnerable Executable shared library data : Vulnerable Ingo From nobody Sun Nov 9 12:20:32 2003 Path: main.gmane.org!not-for-mail From: Graham Wilson Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 00:28:51 -0600 Lines: 40 Approved: news@gmane.org Message-ID: <20031105062851.GA1197@quux.opus.geek> References: <3FA82434.17565.5937549@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" X-Trace: sea.gmane.org 1068013762 7115 80.91.224.253 (5 Nov 2003 06:29:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 06:29:22 +0000 (UTC) Cc: pageexec@freemail.hu, debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 07:29:20 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHHAO-00035l-00 for ; Wed, 05 Nov 2003 07:29:20 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 8AEE31F9B4; Wed, 5 Nov 2003 00:29:02 -0600 (CST) Old-Return-Path: Original-Received: from decoy.wox.org (206.180.133.7.adsl.hal-pc.org [206.180.133.7]) by murphy.debian.org (Postfix) with ESMTP id 8F8FA1F99D for ; Wed, 5 Nov 2003 00:28:54 -0600 (CST) Original-Received: from quux.opus.geek (bluesocket.utdallas.edu [129.110.39.12]) by decoy.wox.org (Postfix) with ESMTP id C2D6D273D3; Wed, 5 Nov 2003 00:28:52 -0600 (CST) Original-Received: by quux.opus.geek (Postfix, from userid 1000) id A597C74426; Wed, 5 Nov 2003 00:28:51 -0600 (CST) Original-To: Ingo Molnar Mail-Followup-To: Ingo Molnar , pageexec@freemail.hu, debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: A0A7 AE54 665D 6446 F2D9 81FF 8B94 031D 7F75 635F X-GPG-Key: http://decoy.wox.org/~bob/public.asc User-Agent: Mutt/1.5.4i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155084 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 00:29:02 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44468 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44468 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 05, 2003 at 02:49:39AM +0100, Ingo Molnar wrote: > On Tue, 4 Nov 2003 pageexec@freemail.hu wrote: > > [...] > [...] Please, guys, don't have your discussion here. I don't think we really care about the differences between PaX and exec-shield. Debian is not, and, to the best of my knowledge, will not, choose one for its kernels, so there is no need to prove that one or the other is better. --=20 gram --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: http://decoy.wox.org/~bob/public.asc iQEVAwUBP6iYoy6fnYH5E4SWAQJM/AgArgVE1+ubNoMp6HmKcfytVttIM6RwROit cmE4j8SqfHFB9yTOpt1yqRze2IKd51ZUYbuhBHOt6QJWtlmcYeakRwpdVT6F6tvQ 9q6W1fIh5iXUlixj9JynTyaSSt7br9WtplweCB/jSxI/LCGh2+b1ncb6aXWmss23 yTJNMPX/18Za+9dLNX77z90I+7KbgavRVd9+tIRhOYeTJYz59YUqs4vvBtzpdFJr nyx7KzedPyQOpiHd5f//60J+1x3mxoU5vrkAM6JTH/iqV08UeuVY1iJvYKpNAu+0 Ka6ZG79LEhzh+qoIsoy0Nhw330c3CWycndV+FSf/keOw8C0ahA/g/w== =Ri5y -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From nobody Sun Nov 9 12:20:32 2003 Path: main.gmane.org!not-for-mail From: Cameron Patrick Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 15:17:52 +0800 Organization: Parenthesis Conspiracy Lines: 18 Approved: news@gmane.org Message-ID: <20031105071752.GE2637@erdos.home> References: <3FA82434.17565.5937549@localhost> <20031105062851.GA1197@quux.opus.geek> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1068016744 11756 80.91.224.253 (5 Nov 2003 07:19:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 07:19:04 +0000 (UTC) Cc: Ingo Molnar , pageexec@freemail.hu Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 08:19:02 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHHwU-0004dM-00 for ; Wed, 05 Nov 2003 08:19:02 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 3D9C21FA54; Wed, 5 Nov 2003 01:18:08 -0600 (CST) Old-Return-Path: Original-Received: from euclid.home (i115-248.nv.iinet.net.au [203.59.115.248]) by murphy.debian.org (Postfix) with ESMTP id F298B1F3F3 for ; Wed, 5 Nov 2003 01:17:56 -0600 (CST) Original-Received: from erdos.home ([10.0.1.2] helo=erdos) by euclid.home with esmtp (Exim 3.36 #1 (Debian)) id 1AHHvP-00063q-00; Wed, 05 Nov 2003 15:17:55 +0800 Original-Received: from cameron by erdos with local (Exim 3.36 #1 (Debian)) id 1AHHvM-0001Iu-00; Wed, 05 Nov 2003 15:17:52 +0800 Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org, Ingo Molnar , pageexec@freemail.hu Content-Disposition: inline In-Reply-To: <20031105062851.GA1197@quux.opus.geek> User-Agent: Mutt/1.5.4i Resent-Message-ID: <2OtgJD.A.NjG.vQKq_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155085 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 01:18:08 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44469 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44469 On Wed, Nov 05, 2003 at 12:28:51AM -0600, Graham Wilson wrote: | Please, guys, don't have your discussion here. I don't think we really | care about the differences between PaX and exec-shield. Debian is not, | and, to the best of my knowledge, will not, choose one for its kernels, | so there is no need to prove that one or the other is better. Why should it not? If Pax or Exec-shield can be added to the kernel without breaking things, and provide better protection against some types of security holes than a default kernel, then surely there is a case to be made for including one or the other in the stock Debian kernel. ("Without breaking things" is the tricky bit here, of course.) Cameron. From nobody Sun Nov 9 12:20:33 2003 Path: main.gmane.org!not-for-mail From: "Francesco P. Lovergine" Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 05 Nov 2003 12:44:03 +0100 Lines: 22 Sender: Francesco Paolo Lovergine Approved: news@gmane.org Message-ID: <20031105114403.GA6159@firewall.ba.issia.cnr.it> References: <3FA82434.17565.5937549@localhost> <20031105062851.GA1197@quux.opus.geek> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1068032706 21597 80.91.224.253 (5 Nov 2003 11:45:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 11:45:06 +0000 (UTC) Cc: Ingo Molnar , pageexec@freemail.hu Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 12:45:03 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHM5v-0000SS-00 for ; Wed, 05 Nov 2003 12:45:03 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 4D6D01F699; Wed, 5 Nov 2003 05:44:27 -0600 (CST) Old-Return-Path: Original-Received: from area.area.ba.cnr.it (area.area.ba.cnr.it [194.119.200.100]) by murphy.debian.org (Postfix) with ESMTP id 8E1C81F558 for ; Wed, 5 Nov 2003 05:44:09 -0600 (CST) Original-Received: from klecker.iesi.lan (firewall.ba.issia.cnr.it [194.119.201.3]) by area.area.ba.cnr.it (PMDF V6.1 #38534) with ESMTP id <0HNV04QG3N9KWZ@area.area.ba.cnr.it> for debian-devel@lists.debian.org; Wed, 05 Nov 2003 12:44:09 +0100 (MET) Original-Received: from frankie by klecker.iesi.lan with local (Exim 4.24) id 1AHM4y-0001d9-02; Wed, 05 Nov 2003 12:44:04 +0100 In-reply-to: <20031105062851.GA1197@quux.opus.geek> Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org, Ingo Molnar , pageexec@freemail.hu Content-Disposition: inline User-Agent: Mutt/1.5.4i X-GPG-key: finger frankie@db.debian.org X-GPG-fingerprint: 92E4 2D44 336F DF91 5508 23D5 A453 5199 E9F2 C747 X-Spot: Who uses non-free software empoisons you, too. Say him to stop. Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155097 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 05:44:27 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44481 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44481 On Wed, Nov 05, 2003 at 12:28:51AM -0600, Graham Wilson wrote: > On Wed, Nov 05, 2003 at 02:49:39AM +0100, Ingo Molnar wrote: > > On Tue, 4 Nov 2003 pageexec@freemail.hu wrote: > > > [...] > > [...] > > Please, guys, don't have your discussion here. I don't think we really > care about the differences between PaX and exec-shield. Debian is not, > and, to the best of my knowledge, will not, choose one for its kernels, > so there is no need to prove that one or the other is better. > The requested debian-kernels new ML will be the perfect place to start this kind of flame wars :) In the meantime I'm afraid there is not another list, but for d-d, where discussion on this kind of things can be accepted. -- Francesco P. Lovergine From nobody Sun Nov 9 12:20:33 2003 Path: main.gmane.org!not-for-mail From: Yven Johannes Leist Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Fri, 7 Nov 2003 02:57:14 +0100 Organization: xnap Lines: 27 Approved: news@gmane.org Message-ID: <200311070257.14412.leist@xnap.org> References: <3FA82434.17565.5937549@localhost> <20031105062851.GA1197@quux.opus.geek> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1068171472 24435 80.91.224.253 (7 Nov 2003 02:17:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2003 02:17:52 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Fri Nov 07 03:17:50 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHwC6-0004mz-00 for ; Fri, 07 Nov 2003 03:17:50 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id B06581F89F; Thu, 6 Nov 2003 20:16:19 -0600 (CST) Old-Return-Path: Original-Received: from master.debian.org (master.debian.org [146.82.138.7]) by murphy.debian.org (Postfix) with ESMTP id 5747B1F92A for ; Thu, 6 Nov 2003 19:57:28 -0600 (CST) Original-Received: from localhost (fastpage.homelinux.org) [127.0.0.1] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1AHvsO-00044Y-00; Thu, 06 Nov 2003 19:57:28 -0600 Original-Received: from localhost (localhost [127.0.0.1]) by fastpage.homelinux.org (Postfix) with ESMTP id 31E6E431FBF for ; Fri, 7 Nov 2003 02:57:15 +0100 (CET) Original-To: debian-devel@lists.debian.org User-Agent: KMail/1.5.1 In-Reply-To: <20031105062851.GA1197@quux.opus.geek> Content-Disposition: inline Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155225 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 20:16:19 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44609 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44609 On Wednesday 05 November 2003 07:28, Graham Wilson wrote: > On Wed, Nov 05, 2003 at 02:49:39AM +0100, Ingo Molnar wrote: > > On Tue, 4 Nov 2003 pageexec@freemail.hu wrote: > > > [...] > > > > [...] > > Please, guys, don't have your discussion here. I don't think we really > care about the differences between PaX and exec-shield. Debian is not, > and, to the best of my knowledge, will not, choose one for its kernels, > so there is no need to prove that one or the other is better. Well, I for one would love to see a security announcement one day, which contains something like: "All users running the standard Debian kernel are not affected, since the special security features the Debian kernel contains prevent the exploit/attack in question." :) Cheers, Yven -- Yven Johannes Leist - leist@xnap.org http://www.xnap.org/leist/ From nobody Sun Nov 9 12:20:34 2003 Path: main.gmane.org!not-for-mail From: Henning Makholm Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: 07 Nov 2003 07:46:17 +0100 Lines: 20 Sender: makholm@tyr.diku.dk Approved: news@gmane.org Message-ID: References: <3FA82434.17565.5937549@localhost> <20031105062851.GA1197@quux.opus.geek> <200311070257.14412.leist@xnap.org> NNTP-Posting-Host: deer.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1068188553 21344 80.91.224.253 (7 Nov 2003 07:02:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2003 07:02:33 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Fri Nov 07 08:02:31 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AI0da-0000BJ-00 for ; Fri, 07 Nov 2003 08:02:31 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 06FAF1F593; Fri, 7 Nov 2003 01:02:04 -0600 (CST) Old-Return-Path: Original-Received: from hugin.diku.dk (hugin.diku.dk [130.225.96.144]) by murphy.debian.org (Postfix) with SMTP id E422D1F5EC for ; Fri, 7 Nov 2003 00:46:18 -0600 (CST) Original-Received: (qmail 15923 invoked from network); 7 Nov 2003 06:46:18 -0000 Original-Received: from tyr.diku.dk (makholm@130.225.96.226) by hugin.diku.dk with QMQP; 7 Nov 2003 06:46:18 -0000 Original-To: debian-devel@lists.debian.org X-My-Web-page: http://www.diku.dk/~makholm/ In-Reply-To: Yven Johannes Leist's message of "Fri, 7 Nov 2003 02:57:14 +0100" Original-Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 Resent-Message-ID: <71OVoC.A.kWC.rN0q_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155237 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Fri, 7 Nov 2003 01:02:04 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44621 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44621 Scripsit Yven Johannes Leist > Well, I for one would love to see a security announcement one day, which > contains something like: > > "All users running the standard Debian kernel are not affected, since the > special security features the Debian kernel contains prevent the > exploit/attack in question." :) Hm, what I've been able to glean from the discussions seems to imply that any software that's vulnerable to a remote access exploit *without* the kernel-level protection in question, would still at least be vulneable to a DoS attack, killing the server (or whatever) process instead of giving the attacker actual control. So we'd still want to provide security updates to the same extent as without. -- Henning Makholm "Hele toget raslede imens Sjælland fór forbi." From nobody Sun Nov 9 12:20:36 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 05 Nov 2003 17:04:50 +0100 Lines: 421 Approved: news@gmane.org Message-ID: <3FA92DB2.20276.9A08A69@localhost> References: <3FA82434.17565.5937549@localhost> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1068049662 2477 80.91.224.253 (5 Nov 2003 16:27:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 16:27:42 +0000 (UTC) Cc: debian-devel@lists.debian.org, spender@grsecurity.net, Peter Busser Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 17:27:38 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHQVN-00023n-00 for ; Wed, 05 Nov 2003 17:27:37 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 74F6F1FAF4; Wed, 5 Nov 2003 10:25:27 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0604.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id A84FE1F60E for ; Wed, 5 Nov 2003 10:05:13 -0600 (CST) Original-Received: from angel (APastourelles-107-1-9-14.w80-13.abo.wanadoo.fr [80.13.163.14]) by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 21B6228001D1; Wed, 5 Nov 2003 17:05:11 +0100 (CET) Original-To: Ingo Molnar Priority: normal In-reply-to: X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155120 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 10:25:27 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44504 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44504 [metanote: as you can see, we're entering the meta-discussion part and i can very well understand that it's of little if any interest to most you (that includes me btw), so i'll try not to post more here except maybe to discuss technical issues] > > 1. 'It seems that exec-shield does 99% of what PaX does' > > this is not the case and i'm not claiming it. If you feel attacked, please > dont - i'll stipulate that PaX gives better security than exec-shield, ok? in case you didn't realize it, it was not directed at you either. > > - PaX implements perfect non-executable pages on amd64, i386, > > ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has > > some imitation of it only on i386 (it's not true per-page). > > non-executable pages on anything else but i386 is a triviality, as the > hardware and the kernel supports it. There's virtually nothing that PaX or > exec-shield has to add to enable them - they are there. that's what you say because apparently you have never checked it let alone tried. here's a few of these 'trivial' questions for you to answer: 1. how do you do per page non-exec pages on ppc/ppc64? hint, there's no NX bit in their PTE format. try to answer that without looking at PaX first ;-) 2. how do you do per page non-exec pages on mips/mips64? hint, there's no split TLB (let alone NX PTE bit) in the base architecture definition. 3. how do you do per page non-exec pages on sparc64 under linux 2.6? hint, you've reused the last free bit in the PTE. and linux didn't support NX on sparc64 even before 2.6. 4. how do you do per page non-exec pages on sh[34]? hint, there's at most a 'half' split TLB only and no NX PTE bit. 5. how do you do per page non-exec pages without a TLB/MMU (you did claim 'trivial' support for anything but i386)? next, what will you do with the archs where the .plt is in the rwx ELF segment and hence under your scheme would force all of .data/.bss to become executable as well? > lets also point out that exec-shield offers relative randomization of DSOs > to each other, while PaX only randomizes a single base of the DSOs, their > relative addresses remain constant. This way the randomization bits of > exec-shield add up for brute-force attacks. Lets add it that if a limited > exploit can be turned into an information leak then relative randomization > does not help - but it does help if the first exploit itself needs precise > addresses from multiple DSOs. all correct, except for the fact that the whole exercise of per-library randomization is pointless. i say that based on my experience in analyzing bugs and writing exploits for them - admittedly something i can't share with you, so feel free to think otherwise. what i can offer however is a simple observation: if an attacker needs code addresses from more than one library, then he can get them even under Exec-Shield. this is because he can just use the .plt entries of the library whose base address he learned via info-leaking. also, the most likely information leaks that contain library addresses are on the stack - and you can imagine that the stack will likely contain such addresses from more than one region, hence there's little if any advantage of separate randomization. in any case, you're missing the point behind randomization. it's an obscurity feature, however efficient it may turn out to be in certain cases. i did it because it was extremely cheap (speaking of the PaX implementation, not Exec-Shield) so i said 'why not'. randomization serves NO purpose in the grand scheme, it does not provide guaranteed protection against the PaX attack model (arbitrary read/write access to the address space). you don't have an attack model so you can say whatever you want about the details of your randomization, they will of course be 'true' by definition. > > second, paxtest had some bugs which Exec-Shield exposed and made > > Exec-Shield appear better than it is. i've fixed them here and > > expect to release 0.9.5 today or so. the results now look like: > > ( how fair that you give me a chance to run it ... not. ) from the email headers of your answer: Date: Wed, 5 Nov 2003 00:58:30 +0100 (CET) From: Ingo Molnar paxtest 0.9.5 was released hours (!) before that, what are you talking about? > > (1) introduce/execute arbitrary code > > (2) execute existing code out of original program order > > (3) execute existing code in original program order with arbitrary data > > no. no what? are you telling me you know of an exploit technique against a memory corruption bug that does not belong to any of the above categories? because that's what my statement was about. > No offense meant, but i say so because right now i dont see the way to > have a generic and usable Linux system with all the restrictions you are > talking about. If you complete your project and everything works and it's > still the same live, flexible and kicking Linux system that we all know > and love then i was clearly wrong. http://gentoo.oregonstate.edu/experimental/x86/stages/ (i apologize for the inadvertant advocacy here, it's just to show a point, i don't want to start a distro war) the above is the beginning of such work with full PIE and propolice support. or if you're into server-land, check out Adamantix [1] (it was released before Exec-Shield). > Right now it seems to be heading more > in the direction of a prison - but this is just my judgement. In any case, > i did not want to add any of that to exec-shield. I'll leave the prison > guard work to selinux. you're mixing up intrusion prevention (PaX) with access control. see more below for the 'prison' argument. > you do realise that most of those 'exploit techniques' overlap with some > programming concepts, and you think that those concepts are flawed by > design and should be eliminated - i dont agree with this characterisation. putting words into my mouth or can you actually quote me on that? what i'm saying is that there are programming techniques (runtime code generation in this case) that should be handled more carefully than they have been. what PaX does by default FOR NOW is the result of me being cautious (and i have not heard of a single PaX user yet who did not appreciate it) and not having the resources to fix up userland all by myself. this also brings me back to your 'prison' argument and a bigger issue you seem to be not talking about: you said a lot about what you don't agree with in PaX, what exactly prevented you from changing it *yourself*? what prevents *you* from disabling MPROTECT by default for example? speaking further about the 'prison' thing, you said this earlier in another thread: > if you could get rid of the 1.5 GB VM limitation of PaX and if you could > change it to use PT_GNU_STACK to set the process stack's protection bits > then i think there's no need for exec-shield - PaX will provide better > protection at no cost and no tradeoffs. have you changed your mind since then? > > - apps that by their nature want to generate code runtime (e.g., > > java). they're broken for good which many people noticed by now. > > that's good, that was my purpose because i wanted to draw > > attention to the fact that runtime code generation is an > > important privilege that should be carefully managed (as it > > happens to be also one of the exploit techniques). [...] > > i think here we are in a fundamental disagreement. To take it to the > extreme, being able to 'generate code' [ie. allow an application to write > code, etc.] is one of the fundamental properties of any Linux user > account, and hopefully remains so in the future. the ability to create/execute one's own binaries is a privilege too, that's what ACL and Trusted Path Execution systems allow you to control (before you talk about 'fundamental properties' please ask some administrators of user accounts in a corporate or government/military environment). in any case, this is no longer about PaX but how a secure system is to be created - there are as many approaches as many people tried, PaX is only one (piece) of them. > If you take that 'privilege' away you'll take away what drives > Linux forward - a constantly growing pool of programmers. i have the impression that you believe i'm trying to promote PaX to enter the 'main' kernels in its current from. to be clear about it: i am *not*. if someone wanted to do it, i'd have several suggestions before that should happen. such as deciding what is acceptable to be default, how it should be controlled (configure or runtime, etc), how and to what extent buggy userland should be fixed, etc. all these concerns are irrelevant in the current discussion because we're talking about technical merits (or their lack of) of different approaches, not how they should be deployed in the 'real world' - that's a whole another problem and requires more parties to participate. > I dont want good security to rely on the > system's insistence to remove the ability to generate code from as many > codepaths as possible. again, nothing is removed, it's just taken under control (as i said above, don't mistake current PaX defaults with how it should be done when the other building blocks are done). > There's got to be another way to secure those damn > apps ... the price you are willing to pay is i believe way too high. good luck in your trying to fix the problem (speaking of the PaX attack model again here), you'd be the first one to do it without the measures that PaX takes. > > about PaX breaking specs: i urge Ingo and others saying this to > > point me to the precise location in SUSv3 or POSIX 1003.1-2001 > > that PaX conflicts with. [...] > > many areas of PaX conflict with one of the most basic rule of Linux: > > http://lwn.net/Articles/32980/ i hope you realize that Linus's declaration is not on the same level as internationally accepted standards, don't mix them up. as for not breaking userland: sure, that's what i'd like to have as well, but i have only so many hours in a day to work on that. also, you did break userland yourself as well, otherwise how would you explain the patches RedHat made to the XFree86 server? see, there're just cases when userland is plain wrong and must be fixed. on another note, how did you get java to work under Exec-Shield while maintaining all those non-executable regions (see more on this below)? > > about SEGMEXEC and the 1.5GB limit: yes, it's true, yes, it could > > be changed (if one can live with a more limited range for executable > > mappings), [...] > > i'm not sure it's acceptable to put _any_ restriction on the layout of the > user VM. no problem, PaX as it is makes no restrictions on the layout, we'll just be stuck with the 1.5 GB task size on i386 (or the usual 3 GB if you can take the performance hit of PAGEEXEC on i386). > The rule exec-shield follows is this: whenever the kernel gets a > chance to chose it will group mappings smartly, but it will follow > requests for executability no matter what. So while this doesnt _force_ > good protection, for most apps it provides a pretty acceptable layout. > > i guess this is a hard-to-solve philosophy difference again. indeed, especially since your philosophy seems to be 'do something while breaking absolutely no apps' where 'something' is yet to be explained and whatever it is, you still broke apps with it (such as XFree86). > a fair number of users got real happy when we extended the x86 user VM > from 3GB to 4GB. Going from 3 GB to 1.5 GB is really not an option i'm > afraid. It's also not an option to say that "your app is secure only as > long as it fits into 1.5 GB". It also not an option to say "this box is > pretty secure, except for your huge database server". that's your personal opinion. others (e.g., PaX users) have the exact opposite as their personal opinions, so be it ;-). since you've talked so much about what does not fit into 1.5 GB, could you please provide us with a list of applications that are used by the majority of users and fail when run in a 1.5 GB address space? > obsoleted by ia64/amd64 systems anyway. But i'd hate to lose users to > Windows just because distros only support 1.5GB of VM. Windows has a 2 GB userland, seems to be closer to 1.5 than 3. other than that, Microsoft is moving into the PaX direction [2] (i'm referring to runtime code generation and memory protection in particular). > i really dont think we can realistically isolate the code generation > capability and still have a nice and flexible system. it's not about 'isolation' (did you mean 'removal'?) but control. control by the distro maker, system administrator or the end user. what is subject to discussion how it should best be done. you say it should not be done at all, that's your opinion and is in complete disagreement with experts in the information security field. > I dont see anything wrong in apps executing scripts. Or apps writing > scripts and executing them. Or apps doing JIT stuff, or just doing > some quick runtime fixup. there's nothing wrong with it as long as you write bugfree code or don't want guaranteed security from certain exploit methods. there are people who want the latter because they have much at stake and know that the former is not true. > It's quite widely done and it would not be Linux anymore if we try to > exterminate or second-class such techniques. And it's even more common in > the Windows world, and i really hope those Windows apps continue to come > over to Linuxland. i know i'm repeating myself, but i'll say it again: there's no problem with runtime code generation as long as it's under control. let's do it, but be aware of it when it's done because it's a dangerous privilege when abused. come up with a system that allows one to easily define and maintain defaults and policies, and i'll be the happiest person. > static predictable addresses. I dont think this should be tagged via the > binary itself - that is too inflexible. There's already one 'VM size bit' > in the personality mask in the upstream 2.6 kernel: the 3GB flag for > amd64. personalities are something i was thinking of before, but i had a problem which i forget now, i'll take another look at it later. > no, this is not how PT_GNU_STACK works. PT_GNU_STACK not only detects > trampolines, but all those techniques that _might_ point in the direction > of process-stack executability. Such as the use of inline assembly. So the > toolchain pessimistically turns on executability and guarantees that _if_ > the object is marked non-executable, that it certainly needs no executable > stack. i was referring to this patch [3] which deals with trampolines only, thanks for clarifying it. > even the above conservative scheme gave a very high coverage rates, with > just a couple of (well below 10% of all) important apps/libs falling out > of the nonexecutability umbrella. what about code not compiled by gcc? are all those users running with an unsafe default (executable stack) or have broken binaries? > To solve these cases, application writers/packagers can further improve > the accuracy of this scheme by declaring said pieces of code as permitting > non-executable, but it's the right place and the best way to document it: > in the source. It cannot get lost, it will be updated when the code is > changed, etc. Tags tend to get lost, or tend to get incorrect over time. doing it in the source code is what i suggested as well, read the proposal in mprotect.txt. [now in order to save some round-trip time, i'll answer your second mail here as well] > i downloaded the new 0.9.5 paxtest package and amongst other changes it > has the following oneliner change: > > --- paxtest-0.9.4/body.c > +++ paxtest-0.9.5/body.c > @@ -29,6 +29,7 @@ > fflush( stdout ); > > if( fork() == 0 ) { > + do_mprotect((unsigned long)argv & ~4095U, 4096, > +PROT_READ|PROT_WRITE|PROT_EXEC); > doit(); > } else { > wait( &status ); > > this intentionally calls mprotect(PROT_EXEC) for the highest possible > address one can think of. This call has no useful purpose at all. In other > words, this is a specific, underhand cheat to trigger 'Vulnerable' > messages for all items when running paxtest on exec-shield kernels. Bravo! > frankly, i've never experienced anything like this in my many years in the > Linux world. You so far gave the impression of a reasonable and balanced > person but this is as low as it gets. Shame on you. several things come to my mind. 1. it's called paxtest for a reason. it's a regression test suite that demonstrates basic exploit techniques and how PaX foils them (or not, as the case may be). in case you don't understand 'regression', it's not about what works, but what does not, therefore it is entirely appropriate for PaX to show its strengths even under circumstances where Exec-Shield fails. as i explain below, chosing between mprotect() and threads came down to the usual question: what takes less time yet demonstrates the effect (one line vs. a hundred or so in my case). beyond all this, feel free to write your own suite. 2. did you miss this in my first post: > Executable anonymous mapping : Vulnerable > Executable bss : Vulnerable > Executable data : Vulnerable > Executable heap : Vulnerable > Executable stack : Vulnerable > the above changes are the result of Ingo's approach to create > non-executable memory on i386, they're not per page as a simple > mprotect on the top of the stack shows. before i get accused of > specifically rigging the tests, i'll tell you that running > multithreaded apps would have almost the same effect (only the > main stack would stay non-exec under Exec-Shield). needless to > say, PaX passes all the above as before. do you understand what i'm saying there? did you also check the changelog which says this: * Non-executable page tests expose incomplete implementations do you disagree that paxtest exposes a weakness in Exec-Shield or not? do you disagree that the exposed weakness can very well occur in real life or not? let me get back to the topic of java as i promised above. java is a nice animal as it shows several issues with Exec-Shield. first of all, it's multithreaded. glibc creates executable thread stacks by default. unfortunately for Exec-Shield, when such stacks are created, everything below them becomes executable as well, even if it was not requested by the application. you call that a feature i assume, i call it a bug (if i mmap() something without PROT_EXEC i don't want the OS to change it to executable behind my back - *that* is really not compliant with standards). second, java has a small piece of executable code in its .data segment - that should break it quite early during startup. how come you never run into it if, as you claim, .data is non-executable? 3. you and others have (ab)used paxtest long enough to justify the approach taken by Exec-Shield while 'forgetting' to point out the weaknesses/limitations (e.g., show me a single post of yours where you discuss the problem with multithreaded apps, or the more generic issue of unexpected and standard breaking memory protection changes). forgive me if i'm not willing to assist to this any longer, but *that* would make me feel really ashamed. [1] http://adamantix.org [2] http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnwxp/html/securityinxpsp2.asp [3] http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00302.html From nobody Sun Nov 9 12:20:37 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 18:37:13 +0100 (CET) Lines: 39 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA82434.17565.5937549@localhost> <3FA92DB2.20276.9A08A69@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068053979 15923 80.91.224.253 (5 Nov 2003 17:39:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 17:39:39 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 18:39:37 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHRd3-0007q2-00 for ; Wed, 05 Nov 2003 18:39:37 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C15A91FB43; Wed, 5 Nov 2003 11:38:36 -0600 (CST) Old-Return-Path: Original-Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by murphy.debian.org (Postfix) with ESMTP id 5CF8A1FB1B for ; Wed, 5 Nov 2003 11:38:29 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id D2A7644C9F; Wed, 5 Nov 2003 18:37:15 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 70CCB1FC2; Wed, 5 Nov 2003 18:37:15 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FA92DB2.20276.9A08A69@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155122 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 11:38:36 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44506 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44506 On Wed, 5 Nov 2003 pageexec@freemail.hu wrote: > > i downloaded the new 0.9.5 paxtest package and amongst other changes it > > has the following oneliner change: [...] > > + do_mprotect((unsigned long)argv & ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC); > first of all, it's multithreaded. [...] paxtest does not link to libpthread, nor does it create threads, at all. How can you claim it's multithreaded? > glibc creates executable thread stacks by default. [...] to the contrary, glibc does this: 00594000-005a1000 r-xp 00000000 09:00 735400 /lib/tls/libpthread-0.60.so 005a1000-005a2000 rw-p 0000c000 09:00 735400 /lib/tls/libpthread-0.60.so 005a2000-005a4000 rw-p 00000000 00:00 0 0063b000-00650000 r-xp 00000000 09:00 730361 /lib/ld-2.3.2.so 00650000-00651000 rw-p 00015000 09:00 730361 /lib/ld-2.3.2.so 00e25000-00f58000 r-xp 00000000 09:00 735396 /lib/tls/libc-2.3.2.so 00f58000-00f5b000 rw-p 00132000 09:00 735396 /lib/tls/libc-2.3.2.so 00f5b000-00f5e000 rw-p 00000000 00:00 0 08048000-08049000 r-xp 00000000 09:02 5226629 /tmp/test 08049000-0804a000 rw-p 00000000 09:02 5226629 /tmp/test 09e9c000-09ebd000 rw-p 00000000 00:00 0 beba6000-beba7000 ---p 00000000 00:00 0 <== thread stack guard page beba7000-bf5a8000 rw-p 00001000 00:00 0 <== non-exec thread stack bf5be000-bf5bf000 rw-p 00000000 00:00 0 bfe79000-c0000000 rw-p fff5d000 00:00 0 $ rpm -q glibc glibc-2.3.2-101 Ingo From nobody Sun Nov 9 12:20:37 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 05 Nov 2003 20:07:02 +0100 Lines: 53 Approved: news@gmane.org Message-ID: <3FA95866.28585.A475957@localhost> References: <3FA92DB2.20276.9A08A69@localhost> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1068060198 31175 80.91.224.253 (5 Nov 2003 19:23:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 19:23:18 +0000 (UTC) Cc: debian-devel@lists.debian.org, Peter Busser , spender@grsecurity.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 20:23:15 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHTFK-0006wH-00 for ; Wed, 05 Nov 2003 20:23:14 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 054B01FB84; Wed, 5 Nov 2003 13:22:53 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0602.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id 1382A1F6AC for ; Wed, 5 Nov 2003 13:07:25 -0600 (CST) Original-Received: from angel (APastourelles-107-1-9-14.w80-13.abo.wanadoo.fr [80.13.163.14]) by mwinf0602.wanadoo.fr (SMTP Server) with ESMTP id 8EA505400311; Wed, 5 Nov 2003 20:07:23 +0100 (CET) Original-To: Ingo Molnar Priority: normal In-reply-to: X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155126 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 13:22:53 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44510 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44510 > > first of all, it's multithreaded. [...] > > paxtest does not link to libpthread, nor does it create threads, at all. > How can you claim it's multithreaded? i did not. if you quote my post like this: > let me get back to the topic of java as i promised above. java > is a nice animal as it shows several issues with Exec-Shield. > > first of all, it's multithreaded. glibc creates executable > thread stacks by default. [...] it will be clear that i was referring to java. > > glibc creates executable thread stacks by default. [...] > > to the contrary, glibc does this: > [snip] > $ rpm -q glibc > glibc-2.3.2-101 that's what RedHat's glibc does. and this is what i get on gentoo (again, sorry for the plug, although i think other distros like debian would show the same as well): $ epm -q glibc glibc-2.3.2-r8 excerpt from the maps file of /opt/blackdown-jdk-1.4.1/bin/java (running under PaX but without non-exec pages, randomization was still on): b7b7f000-b7b80000 +++p 00000000 00:00 0 b7b80000-b7b8e000 RWXp 00001000 00:00 0 b7b8e000-b7b91000 +++p 0000f000 00:00 0 b7b91000-b7c00000 RWXp 00012000 00:00 0 b7d7f000-b7d80000 +++p 00000000 00:00 0 b7d80000-b7d8e000 RWXp 00001000 00:00 0 b7d8e000-b7d91000 +++p 0000f000 00:00 0 b7d91000-b7e00000 RWXp 00012000 00:00 0 b7f7f000-b7f80000 +++p 00000000 00:00 0 b7f80000-b8000000 RWXp 00001000 00:00 0 b8500000-b850a000 RWXp 00000000 00:00 0 b850a000-b850d000 +++p 00000000 00:00 0 b86f2000-b86fb000 RWXp ffff8000 00:00 0 regardless of whether RedHat fixed this or not (i hope it will enter the main glibc tree btw), the fundemantal problem of changing memory protections without asking stays there (LinuxThreads was just one known way to trigger it). From nobody Sun Nov 9 12:20:37 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 21:39:52 +0100 (CET) Lines: 18 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA92DB2.20276.9A08A69@localhost> <3FA95866.28585.A475957@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068064836 9738 80.91.224.253 (5 Nov 2003 20:40:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 20:40:36 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 21:40:33 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHUS9-0003dr-00 for ; Wed, 05 Nov 2003 21:40:33 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 242091F74D; Wed, 5 Nov 2003 14:40:01 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id 0DA851F451 for ; Wed, 5 Nov 2003 14:39:55 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id 4CE2549290; Wed, 5 Nov 2003 21:39:54 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id C38041FC2; Wed, 5 Nov 2003 21:39:53 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FA95866.28585.A475957@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155132 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 14:40:01 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44516 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44516 On Wed, 5 Nov 2003 pageexec@freemail.hu wrote: > > > glibc creates executable thread stacks by default. [...] > > > > to the contrary, glibc does this: > > [snip] > > $ rpm -q glibc > > glibc-2.3.2-101 > > that's what RedHat's glibc does. [...] yes. The changes are in mainline glibc, everyone will pick those changes up with time. Ingo From nobody Sun Nov 9 12:20:37 2003 Path: main.gmane.org!not-for-mail From: Peter Busser Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 20:23:56 +0100 Lines: 45 Approved: news@gmane.org Message-ID: <20031105192356.GA24483@adamantix.org> References: <3FA82434.17565.5937549@localhost> <3FA92DB2.20276.9A08A69@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1068061346 1498 80.91.224.253 (5 Nov 2003 19:42:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 19:42:26 +0000 (UTC) Cc: mingo@elte.hu, debian-devel@lists.debian.org, spender@grsecurity.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 20:42:24 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHTXr-0008J7-00 for ; Wed, 05 Nov 2003 20:42:23 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 662E91FB91; Wed, 5 Nov 2003 13:41:48 -0600 (CST) Old-Return-Path: Original-Received: from mail.adamantix.org (unknown [212.204.216.41]) by murphy.debian.org (Postfix) with ESMTP id 916831FB73 for ; Wed, 5 Nov 2003 13:25:31 -0600 (CST) Original-Received: by mail.adamantix.org (Postfix, from userid 1000) id 75A1F6B649; Wed, 5 Nov 2003 20:23:56 +0100 (CET) Original-To: pageexec@freemail.hu Content-Disposition: inline In-Reply-To: <3FA92DB2.20276.9A08A69@localhost> User-Agent: Mutt/1.3.28i Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155129 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 13:41:48 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44513 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44513 Hi! > > this intentionally calls mprotect(PROT_EXEC) for the highest possible > > address one can think of. This call has no useful purpose at all. In other > > words, this is a specific, underhand cheat to trigger 'Vulnerable' > > messages for all items when running paxtest on exec-shield kernels. Bravo! If you get bad grades on school, don't work harder, blame the teacher. Other people have been asking for such a test, because there was speculation about this vulnerability in exec-shield. It is in fact a simulation of a multithreaded application. I objected to adding tests that include a multi- threaded library, because the library might interfere with the results of the test. So instead of adding a library that would perform the mprotect(), the mprotect() itself was added. Since multi-threaded applications are not that uncommon. Therefore the results are quite relevant I think. People deserve to know what the limitations the security products they use have. That is why the return to function tests have been included, to show that PaX is good but not perfect. Paxtest simply shows if people tell the truth about memory protection patches. I wrote it to see if what pageexec told me about it was true or not, so I wouldn't lie to people when I tell them Adamantix has good memory protection. There are already too many lies in the security world that there is no need for even more. And after all, if exec-shield is being included in the Debian default kernel source, then you are talking about the pride of a 1000 developers that are at stake here. That is not something you should take lightly if you ask me. :-) > > frankly, i've never experienced anything like this in my many years in the > > Linux world. You so far gave the impression of a reasonable and balanced > > person but this is as low as it gets. Shame on you. Do you have the detailed specification of exec-shield somewhere? That would make it easier to evaluate the completeness of the test suite. Feel free to submit tests yourself, I'll add any sensible test. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ From nobody Sun Nov 9 12:20:37 2003 Path: main.gmane.org!not-for-mail From: Adam Heath Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 13:54:49 -0600 (CST) Lines: 10 Approved: news@gmane.org Message-ID: References: <20031105192356.GA24483@adamantix.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068062704 4682 80.91.224.253 (5 Nov 2003 20:05:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 20:05:04 +0000 (UTC) Cc: pageexec@freemail.hu, , , Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 21:05:01 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHTtl-0001OB-00 for ; Wed, 05 Nov 2003 21:05:01 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 6E2941F773; Wed, 5 Nov 2003 14:04:46 -0600 (CST) Old-Return-Path: Original-Received: from gradall.private.brainfood.com (brown.brainfood.com [146.82.138.61]) by murphy.debian.org (Postfix) with ESMTP id 7E44B1F4DC for ; Wed, 5 Nov 2003 14:04:42 -0600 (CST) Original-Received: from localhost ([127.0.0.1] ident=adam) by gradall.private.brainfood.com with esmtp (Exim 3.36 #1 (Debian)) id 1AHTju-0000Da-00; Wed, 05 Nov 2003 13:54:50 -0600 X-X-Sender: adam@gradall.private.brainfood.com Original-To: Peter Busser In-Reply-To: <20031105192356.GA24483@adamantix.org> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155130 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 14:04:46 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44514 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44514 On Wed, 5 Nov 2003, Peter Busser wrote: > And after all, if exec-shield is being included in the Debian default kernel > source, then you are talking about the pride of a 1000 developers that are at > stake here. That is not something you should take lightly if you ask me. :-) You mean the single developer who maintains the standard debian kernel, or the single developer who maintains the execshield or pax patches. From nobody Sun Nov 9 12:20:38 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 21:49:56 +0100 (CET) Lines: 69 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA82434.17565.5937549@localhost> <3FA92DB2.20276.9A08A69@localhost> <20031105192356.GA24483@adamantix.org> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068065450 11145 80.91.224.253 (5 Nov 2003 20:50:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 20:50:50 +0000 (UTC) Cc: pageexec@freemail.hu, debian-devel@lists.debian.org, spender@grsecurity.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 21:50:47 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHUc3-0004HK-00 for ; Wed, 05 Nov 2003 21:50:47 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 7A0F71F7CB; Wed, 5 Nov 2003 14:50:13 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id B29E01F676 for ; Wed, 5 Nov 2003 14:50:00 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id 1F8FA48F4F; Wed, 5 Nov 2003 21:49:59 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 95E581FC2; Wed, 5 Nov 2003 21:49:58 +0100 (CET) Original-To: Peter Busser In-Reply-To: <20031105192356.GA24483@adamantix.org> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155134 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 14:50:13 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44518 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44518 On Wed, 5 Nov 2003, Peter Busser wrote: > It is in fact a simulation of a multithreaded application. [...] The test incorrectly assumes that thread stacks are executable. I suspect we both agree that it's desirable to have thread stacks non-executable as well. > I objected to adding tests that include a multi- threaded library, > because the library might interfere with the results of the test. in fact it's desirable to properly have the same 'effect' a pthread library has - after all that 'effect' might have security relevance. The best way to do that is to use the threading library used by virtually all applications on the box where the test is running: -lpthread. > [...] Feel free to submit tests yourself, I'll add any sensible test. yep, proper threaded test added. This should put this episode to rest. Ingo diff -rNu paxtest-0.9.5/body.c paxtest-0.9.5/body.c --- paxtest-0.9.5/body.c +++ paxtest-0.9.5/body.c @@ -13,6 +13,13 @@ #include #include #include +#include + +static void *test_thread(void *p) +{ + pause(); + return NULL; +} #ifndef PAGESIZE #define PAGESIZE (4096) @@ -29,8 +36,13 @@ fflush( stdout ); if( fork() == 0 ) { - do_mprotect((unsigned long)argv & ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC); + pthread_t thread; + + pthread_create(&thread, NULL, test_thread, NULL); + doit(); + + pthread_kill(&thread, SIGTERM); } else { wait( &status ); if( WIFEXITED(status) == 0 ) { diff -rNu paxtest-0.9.5/Makefile.generic paxtest-0.9.5/Makefile.generic --- paxtest-0.9.5/Makefile.generic +++ paxtest-0.9.5/Makefile.generic @@ -2,7 +2,7 @@ CC=gcc CFLAGS=-O2 -LDFLAGS= +LDFLAGS=-lpthread ifndef RUNDIR RUNDIR=. endif From nobody Sun Nov 9 12:20:38 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 06 Nov 2003 17:13:33 +0100 Lines: 19 Approved: news@gmane.org Message-ID: <3FAA813D.26031.ECEE228@localhost> References: <20031105192356.GA24483@adamantix.org> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1068136258 17726 80.91.224.253 (6 Nov 2003 16:30:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 16:30:58 +0000 (UTC) Cc: debian-devel@lists.debian.org, spender@grsecurity.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 17:30:55 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHn27-0006Ca-00 for ; Thu, 06 Nov 2003 17:30:55 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id ECE6F1F5F9; Thu, 6 Nov 2003 10:30:27 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0602.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id C61321F4B5 for ; Thu, 6 Nov 2003 10:13:56 -0600 (CST) Original-Received: from angel (APastourelles-107-1-11-158.w217-128.abo.wanadoo.fr [217.128.154.158]) by mwinf0602.wanadoo.fr (SMTP Server) with ESMTP id B05F8540026D; Thu, 6 Nov 2003 17:13:55 +0100 (CET) Original-To: Peter Busser , Ingo Molnar Priority: normal In-reply-to: X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155178 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 10:30:27 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44562 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44562 > > It is in fact a simulation of a multithreaded application. [...] > > The test incorrectly assumes that thread stacks are executable. I suspect > we both agree that it's desirable to have thread stacks non-executable as > well. while i agree with you on this one, it is in stark contrast to what you said earlier: > there's nothing wrong about an executable stack though. It's been part of > Linux ever since. also, the test does not only demonstrate that thread stacks are executable or not, it demonstrates a fundemental design flaw in Exec-Shield: whenever an executable region is created in the address space, *everything* below that becomes executable as well. i believe it is important that Exec-Shield users are aware of this flaw, could you write a test for this as well please? From nobody Sun Nov 9 12:20:38 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 6 Nov 2003 17:59:35 +0100 (CET) Lines: 79 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <20031105192356.GA24483@adamantix.org> <3FAA813D.26031.ECEE228@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068138075 22700 80.91.224.253 (6 Nov 2003 17:01:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 17:01:15 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 18:01:12 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHnVQ-0000U6-00 for ; Thu, 06 Nov 2003 18:01:12 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 146941F860; Thu, 6 Nov 2003 11:00:50 -0600 (CST) Old-Return-Path: Original-Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by murphy.debian.org (Postfix) with ESMTP id D4C7C1F601 for ; Thu, 6 Nov 2003 11:00:41 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id 32AAC47064; Thu, 6 Nov 2003 17:59:39 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id D846D1FC4; Thu, 6 Nov 2003 17:59:38 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FAA813D.26031.ECEE228@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155184 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 11:00:50 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44568 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44568 On Thu, 6 Nov 2003 pageexec@freemail.hu wrote: > > The test incorrectly assumes that thread stacks are executable. I suspect > > we both agree that it's desirable to have thread stacks non-executable as > > well. > > while i agree with you on this one, it is in stark contrast to what you > said earlier: > > > there's nothing wrong about an executable stack though. It's been part of > > Linux ever since. sorry but i really have to say that your logic is flawed. (It's sad to see when a discussion deteriorates to such a stage and i've decided to stop it from my side, see more below. [ thousands of debian-devel readers rejoice :-) ] ) "The test incorrectly assumes that thread stacks are executable" is not equivalent to "thread stacks are non-executable". And there's no conflict in what i say above. all i'm saying is that each and every application has a fair right to assume an executable stack. _If_ tools find (or developer asserts it, in the source) that a particular application does _not_ need an executable stack then it's perfectly fine for the OS to go for it and enable a non-executable stack! you should not do this decision for the application/library in one way or another. > also, the test does not only demonstrate that thread stacks are > executable or not, it demonstrates a fundemental design flaw in > Exec-Shield: whenever an executable region is created in the address > space, *everything* below that becomes executable as well. [...] thanks, the cat is finally out of the bag - you admit here that the incriminating paxtest code is there to demonstrate what you characterise as a flaw in exec-shield. Note that none of your arguments tries to claim that any real application indeed does "mprotect(argv)", which is pretty telling by itself. As i have explained it a hundred times, this behavior is a well-known property of exec-shield, and that we've done a quite good job of reducing this effect. In fact i've put it into my exec-shield announcement: # Limitations: # ------------ # # also, if the overflow is within the exec-shield itself (e.g. within the # data section of one of the shared library objects in the ASCII-armor) # then the overflow might be possible to exploit. # # [...] # All in one, exec-shield is one barrier against attacks, not blanket 100% # protection in any way. The most efficient security can be provided by # installing as many layers as possible. But you dont have to believe me, you can try it yourself, install an exec-shield distro and measure the effect of this exec-shield property. ( sorry, but i'm going to stop contributing to this thread. You are getting increasingly irrational and emotional, there's nothing more i could add to this thread. I do acknowledge that PaX is more secure, but i also say that exec-shield is a hell alot of a difference from a stock distro. You expressed your feelings that exec-shield is insecure in one area and apparently you conclude that it's thus useless. There's nothing i can do to change this irrational bad logic of yours. ) Ingo ps. for those who'd like to get rid of this thread too, put this into your .procmailrc: :0: * ^Subject:.*Exec-Shield vs. PaX /dev/null From nobody Sun Nov 9 12:20:38 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Fri, 07 Nov 2003 12:15:06 +0100 Lines: 123 Approved: news@gmane.org Message-ID: <3FAB8CCA.7948.12E4009E@localhost> References: <3FAA813D.26031.ECEE228@localhost> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1068204934 27271 80.91.224.253 (7 Nov 2003 11:35:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2003 11:35:34 +0000 (UTC) Cc: debian-devel@lists.debian.org, spender@grsecurity.net, Peter Busser , henning@makholm.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Fri Nov 07 12:35:31 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AI4tm-0007yN-00 for ; Fri, 07 Nov 2003 12:35:30 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 0595F1F9A8; Fri, 7 Nov 2003 05:35:11 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0601.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id 87DEF1F4AF for ; Fri, 7 Nov 2003 05:15:31 -0600 (CST) Original-Received: from angel (APastourelles-107-1-18-151.w81-49.abo.wanadoo.fr [81.49.132.151]) by mwinf0601.wanadoo.fr (SMTP Server) with ESMTP id 26AC63400133; Fri, 7 Nov 2003 12:15:29 +0100 (CET) Original-To: Ingo Molnar Priority: normal In-reply-to: X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155245 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Fri, 7 Nov 2003 05:35:11 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44629 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44629 > "The test incorrectly assumes that thread stacks are executable" is not > equivalent to "thread stacks are non-executable". And there's no conflict > in what i say above. ok, i was quoting too much and you interpreted the wrong part. the bit i was referring to is this: > I suspect we both agree that it's desirable to have thread stacks > non-executable as well. on one hand you acknowledge that it's better to have non-exec thread stacks but on the other hand you argued that > it's not a bugfix to break apps that rely on an executable stack - the > stack _is_ executable. ^^^^^^^^^^^^^^^^^^^^^ as they say, you can't have it both ways. > > also, the test does not only demonstrate that thread stacks are > > executable or not, it demonstrates a fundemental design flaw in > > Exec-Shield: whenever an executable region is created in the address > > space, *everything* below that becomes executable as well. [...] > > thanks, the cat is finally out of the bag - you admit here that the > incriminating paxtest code is there to demonstrate what you characterise > as a flaw in exec-shield. the cat has always been out of the bag, way back in my very first mail in this thread (and it's now the second time i've quoted this bit): > Executable anonymous mapping : Vulnerable > Executable bss : Vulnerable > Executable data : Vulnerable > Executable heap : Vulnerable > Executable stack : Vulnerable > > the above changes are the result of Ingo's approach to create > non-executable memory on i386, they're not per page as a simple > mprotect on the top of the stack shows. before i get accused of > specifically rigging the tests, i'll tell you that running > multithreaded apps would have almost the same effect (only the > main stack would stay non-exec under Exec-Shield). needless to > say, PaX passes all the above as before. since you have such a problem with paxtest doing the explicit mprotect() itself i decided to change it to a simple nested function, it will achieve the same and hopefully satisfy you as well. > Note that none of your arguments tries to claim > that any real application indeed does "mprotect(argv)", which is pretty > telling by itself. indeed. if you read my mails again (i'm getting tired of quoting myself all over again), i told you explicitly what paxtest is for: testing for regressions, situations when stuff fails. Exec-Shield fails under the above mentioned situation. it also fails when gcc nested functions are used, you'll see that in 0.9.6. i hope you won't argue that no real application uses nested functions (and before you object even to that, as you said yourself, nested functions are just one way to trigger the heuristics in gcc, other code constructs from real life would do the same as well). > As i have explained it a hundred times, this behavior is a well-known > property of exec-shield, and that we've done a quite good job of reducing > this effect. In fact i've put it into my exec-shield announcement: *none* of your public postings discusses the inherent problem with memory regions becoming executable when something above them does. the quote from your README talks about the ascii-armor region and data being executable in there. it does not talk about how the main application's data or the heap or even the entire stack can become unexpectedly executable. on a related note, PT_GNU_STACK support as implemented in Exec-Shield suffers from the same problem: you make not only the stack executable but *everything* else below it, i could not find a note from you talking about it. > ( sorry, but i'm going to stop contributing to this thread. You are > getting increasingly irrational and emotional, there's nothing more i > could add to this thread. I do acknowledge that PaX is more secure, but i > also say that exec-shield is a hell alot of a difference from a stock > distro. You expressed your feelings that exec-shield is insecure in one > area and apparently you conclude that it's thus useless. There's nothing i > can do to change this irrational bad logic of yours. ) Ingo, if you read one of my previous posts, you will realize that i did say that Exec-Shield was mostly good enough against current exploit methods (which blindly expect their injected payload to be executable). what it's not good enough for is protecting against future attacks which will (because they can) adapt and circumvent Exec-Shield in certain cases. this is not true for PaX and obviously that decides what i'm going to use (and have been for all these past 3 years). and finally on a personal note: you're quick to call people by names, that's not professional especially when none of the facts support your position. ------------------------------------------------------------------- i was not cc'd on this, but i'd still like to reply here: Henning Makholm said: > Hm, what I've been able to glean from the discussions seems to imply > that any software that's vulnerable to a remote access exploit > *without* the kernel-level protection in question, would still at > least be vulneable to a DoS attack, killing the server (or whatever) > process instead of giving the attacker actual control. So we'd still > want to provide security updates to the same extent as without. you're absolutely correct, there is *no* substitute to using correct software. intrusion prevention systems exist for the purpose to provide some level of protection until such an update can be made and installed. there are many reasons why it may not always happen in a timely manner. for one, there are bugs which are simply not known publicly (the 0-day exploit case), or there're services/servers which cannot be taken down in certain hours of the day (and the risk of a DoS is still more acceptable than the risk of getting compromised), or the system admin is simply too busy to install the update as soon as it's released (full automation of software updates carries its risks as well as i'm sure many admins can tell). From nobody Sun Nov 9 12:20:40 2003 Path: main.gmane.org!not-for-mail From: Cameron Patrick Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Fri, 7 Nov 2003 19:45:58 +0800 Organization: Parenthesis Conspiracy Lines: 28 Approved: news@gmane.org Message-ID: <20031107114557.GL3210@erdos.home> References: <3FAA813D.26031.ECEE228@localhost> <3FAB8CCA.7948.12E4009E@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1068205613 29011 80.91.224.253 (7 Nov 2003 11:46:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2003 11:46:53 +0000 (UTC) Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Fri Nov 07 12:46:51 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AI54l-00008t-00 for ; Fri, 07 Nov 2003 12:46:51 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id C4C481F96C; Fri, 7 Nov 2003 05:46:19 -0600 (CST) Old-Return-Path: Original-Received: from euclid.home (i250-006.nv.iinet.net.au [203.59.250.6]) by murphy.debian.org (Postfix) with ESMTP id D3CB71F4C8 for ; Fri, 7 Nov 2003 05:45:59 -0600 (CST) Original-Received: from erdos.home ([10.0.1.2] helo=erdos) by euclid.home with esmtp (Exim 3.36 #1 (Debian)) id 1AI53u-0006Ss-00 for ; Fri, 07 Nov 2003 19:45:58 +0800 Original-Received: from cameron by erdos with local (Exim 3.36 #1 (Debian)) id 1AI53u-0001xp-00 for ; Fri, 07 Nov 2003 19:45:58 +0800 Original-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org Content-Disposition: inline In-Reply-To: <3FAB8CCA.7948.12E4009E@localhost> User-Agent: Mutt/1.5.4i Resent-Message-ID: <8LbrTD.A.JCH.LY4q_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155246 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Fri, 7 Nov 2003 05:46:19 -0600 (CST) Resent-Bcc: Xref: main.gmane.org gmane.linux.debian.devel.general:44630 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44630 On Fri, Nov 07, 2003 at 12:15:06PM +0100, pageexec@freemail.hu wrote: | > I suspect we both agree that it's desirable to have thread stacks | > non-executable as well. | | on one hand you acknowledge that it's better to have non-exec thread | stacks but on the other hand you argued that | | > it's not a bugfix to break apps that rely on an executable stack - the | > stack _is_ executable. | ^^^^^^^^^^^^^^^^^^^^^ | | as they say, you can't have it both ways. He's saying that there's no reason to have an executable stack for programs which never attempt to execute code on the stack---and having a non-executable stack in such circumstances gives you a security advantage---but it is not okay for the operating system to break those programs which /do/ rely on the stack being executable. Now could you please stop wasting everybody's time by continuing this thread? Ingo has already stated that he won't continue arguing with you, and I don't intend to continue posting in this thread after this message either. Cameron. From nobody Sun Nov 9 12:20:40 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Wed, 5 Nov 2003 23:29:08 +0100 (CET) Lines: 170 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA82434.17565.5937549@localhost> <3FA92DB2.20276.9A08A69@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068071526 14080 80.91.224.253 (5 Nov 2003 22:32:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2003 22:32:06 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Wed Nov 05 23:32:04 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHWC3-0003F1-00 for ; Wed, 05 Nov 2003 23:32:04 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 703681F85F; Wed, 5 Nov 2003 16:30:58 -0600 (CST) Old-Return-Path: Original-Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by murphy.debian.org (Postfix) with ESMTP id 813C71F499 for ; Wed, 5 Nov 2003 16:30:28 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id 55886472A3; Wed, 5 Nov 2003 23:29:10 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 117A91FC2; Wed, 5 Nov 2003 23:29:10 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FA92DB2.20276.9A08A69@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155139 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Wed, 5 Nov 2003 16:30:58 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44523 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44523 On Wed, 5 Nov 2003 pageexec@freemail.hu wrote: > > non-executable pages on anything else but i386 is a triviality, as the > > hardware and the kernel supports it. There's virtually nothing that PaX or > > exec-shield has to add to enable them - they are there. You are right that the other architectures you listed need alot of nontrivial work and PaX did it very nicely. The two architectures that will likely capture more than 90% of the CPU market in the next 10 years, ia64 and amd64 both have executable bits in their pte formats. These need no extra work. My sentence above should be "any of the x86 successors", instead of "anything else". [ i accept your points wrt. relative randomization. ] > [...] randomization serves NO purpose in the grand scheme, it does not > provide guaranteed protection against the PaX attack model (arbitrary > read/write access to the address space). [...] there's another, practical aspect of address-space randomization which i find to be the most important: to make worms uneconomic in network bandwidth terms. The most effective worm in recent history was a single-packet exploit-and-infect attack, with a high likelyhood to infect a machine via that single packet. If the worm has to guess certain exploit parameters then the introduction of just one other packet can make or break the dynamics of worm propagation - let alone the need for 1024 or 32K packets for a single infection. So randomization does have an important longterm significance. i agree that it's near worthless against local attacks or directed attacks. It might help in eventually bringing more attention to the attack itself but that's not a guarantee. > > > second, paxtest had some bugs which Exec-Shield exposed and made > > > Exec-Shield appear better than it is. i've fixed them here and > > > expect to release 0.9.5 today or so. the results now look like: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > ( how fair that you give me a chance to run it ... not. ) i take this back - you did offer it for download. (I was parsing 'today or so' as 'sometime later' and didnt check your site. I did check it after sending the mail and discovered the new package. Obviously my points wrt. the 'threading change' remain.) > > you do realise that most of those 'exploit techniques' overlap with some > > programming concepts, and you think that those concepts are flawed by > > design and should be eliminated - i dont agree with this characterisation. > > putting words into my mouth or can you actually quote me on that? i did not intend to put anything in your mouth - this is how i understood your paragraph below: > - apps that by their nature want to generate code runtime (e.g., > java). they're broken for good which many people noticed by now. > that's good, that was my purpose because i wanted to draw > attention to the fact that runtime code generation is an > important privilege that should be carefully managed (as it > happens to be also one of the exploit techniques). i took the 'they are broken for good' as equivalent to 'concepts flawed by design', and 'important privilege that should be carefully managed' as a signal of your belief that the ability to generate code should be restricted. I do not agree with this direction. The moment you start to 'manage' stuff that you believe is 'broken for good' it ends up being less accessible to people. (let me know if you think this is an unfair/inaccurate characterisation of your words.) > what i'm saying is that there are programming techniques (runtime code > generation in this case) that should be handled more carefully than they > have been. what PaX does by default FOR NOW is the result of me being > cautious (and i have not heard of a single PaX user yet who did not > appreciate it) and not having the resources to fix up userland all by > myself. [...] my experience is that resources that get 'managed' manually tend to be much less accessible to the average user. Scripting (which is a form of code generation) and generally writing code is the heart of Linux. I would like to see all these security technologies to show up on Joe Average's desktop, so government-style manual need-to-know access control just doesnt cut it. It might work if packaged very very carefully with lots of care towards making it simple, but i see zero efforts in that direction. In fact i got flamed for even mentioning PT_GNU_STACK which i believe is one careful step in that direction. > you said a lot about what you don't agree with in PaX, what exactly > prevented you from changing it *yourself*? what prevents *you* from > disabling MPROTECT by default for example? we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did seem to be a reasonable person with tons of experience and this matters alot when considering patches) and the killer at that time was the 1.5 GB VM limitation on x86. Exec-shield, as coarse as it might be, does here and today offer quite acceptable non-executability coverage of all actual apps we checked, and this is what counts. (Nobody puts bogus mprotect(argv) calls into these apps to disable exec-shield so exec-shield just works.) If you ask any user about security they'll just nod and say it's very important. But when facing them with the cost of security they'll just shout at administration difficulties and broken apps and performance impact, so only a careful and evolutionary approach suffices. Stuff can only be added piece by piece, with frequent backtracks. (Having said that, there's no reason why exec-shield couldnt be exchanged for PaX in the future - most of the security features in Fedora are not related to the dynamic-segmentation-limit thing of exec-shield at all, what precise mechanism enforces the executability permission expressed in the vma is irrelevant, as long as it works.) the mprotect argument came not from my ability to enable or disable it in PaX, but from the claim/impression that the (mprotect) tests in paxtest constitude actual 'Vulnerabilities'. So i simply said i dont intend to restrict mprotect semantics in exec-shield and explained my reasons for doing so. > speaking further about the 'prison' thing, you said this earlier > in another thread: > > > if you could get rid of the 1.5 GB VM limitation of PaX and if you could > > change it to use PT_GNU_STACK to set the process stack's protection bits > > then i think there's no need for exec-shield - PaX will provide better > > protection at no cost and no tradeoffs. > > have you changed your mind since then? no, i havent. PaX is fundamentally finer grained than exec-shield. Eg. exec-shield will never make library data/bss non-executable. The other problems, like thread stacks or apps doing mprotect()s were solved, so all the other exploitable areas are non-executable. > > If you take that 'privilege' away you'll take away what drives > > Linux forward - a constantly growing pool of programmers. > > i have the impression that you believe i'm trying to promote PaX to > enter the 'main' kernels in its current from. [...] this impression of yours is incorrect. PaX as a whole has no chance to get into the kernel in the near future. Nor does exec-shield. (Linus is quite strongly against security related restrictions.) but i'd love it if you could start pushing eg. the arch exec-bit PTE changes into the kernel - those would be very nice to have. > [...] also, you did break userland yourself as well, otherwise how would > you explain the patches RedHat made to the XFree86 server? [...] that was a bugfix - X relied on executability of a non-executable area. The x86 kernel just didnt enforce it. X would crash the same way on amd64 when running in x86 mode, without exec-shield. (in fact X did properly use an executable area on other architectures - just not x86 - the code was #ifdef-ed out on x86.) it's not a bugfix to break apps that rely on an executable stack - the stack _is_ executable. > [...] see, there're just cases when userland is plain wrong and must be > fixed. [...] there's nothing wrong about an executable stack though. It's been part of Linux ever since. Ingo From nobody Sun Nov 9 12:20:40 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 6 Nov 2003 12:25:08 +0100 (CET) Lines: 21 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA82434.17565.5937549@localhost> <3FA92DB2.20276.9A08A69@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068117976 2672 80.91.224.253 (6 Nov 2003 11:26:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 11:26:16 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 12:26:14 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHiHF-0002xA-00 for ; Thu, 06 Nov 2003 12:26:13 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 2C5921F41D; Thu, 6 Nov 2003 05:25:22 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id ACD4E1F505 for ; Thu, 6 Nov 2003 05:25:12 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id B98E949380; Thu, 6 Nov 2003 12:25:11 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 5BBFE1FC4; Thu, 6 Nov 2003 12:25:11 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FA92DB2.20276.9A08A69@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155166 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 05:25:22 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44550 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44550 On Wed, 5 Nov 2003 pageexec@freemail.hu wrote: > [...] also, you did break userland yourself as well, otherwise how would > you explain the patches RedHat made to the XFree86 server? actually, unmodified XFree86 works just fine. It will have an executable stack but it will work out of box - so no app was broken. tuxracer works out of box as well. X does break if you force exec-shield=2, and it did break even with exec-shield=1 in earlier iterations of exec-shield, but that bug has been fixed. the XFree86 patching you refer to above we did was to enable non-exec stack. But this was an iterative thing to enhance security, not something we had to do because X broke due to exec-shield itself. Ingo From nobody Sun Nov 9 12:20:41 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 06 Nov 2003 14:24:06 +0100 Lines: 73 Approved: news@gmane.org Message-ID: <3FAA5986.8511.E33BD52@localhost> References: <3FA92DB2.20276.9A08A69@localhost> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1068126490 21582 80.91.224.253 (6 Nov 2003 13:48:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 13:48:10 +0000 (UTC) Cc: debian-devel@lists.debian.org, Peter Busser , spender@grsecurity.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 14:48:07 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHkUZ-0002Ha-00 for ; Thu, 06 Nov 2003 14:48:07 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 751651F5A3; Thu, 6 Nov 2003 07:47:22 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0604.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id D0CC81F922 for ; Thu, 6 Nov 2003 07:24:28 -0600 (CST) Original-Received: from angel (APastourelles-107-1-11-158.w217-128.abo.wanadoo.fr [217.128.154.158]) by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 7F6EB2800090; Thu, 6 Nov 2003 14:24:27 +0100 (CET) Original-To: Ingo Molnar Priority: normal In-reply-to: X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155168 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 07:47:22 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44552 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44552 > > [...] also, you did break userland yourself as well, otherwise how would > > you explain the patches RedHat made to the XFree86 server? > > actually, unmodified XFree86 works just fine. It will have an executable > stack but it will work out of box - so no app was broken. false! my unmodified X server (gentoo) dies with the following core when trying to run it under [1]: (gdb) bt #0 0x00caf471 in kill () from /lib/libc.so.6 #1 0x00caf215 in raise () from /lib/libc.so.6 #2 0x00cb07bb in abort () from /lib/libc.so.6 #3 0x0806eb99 in AbortDDX () #4 0x080ed43a in FatalError () #5 0x0808522c in xf86SigHandler () #6 #7 0x0a226000 in ?? () #8 0x080a6f98 in LoadModule () #9 0x0806fa3c in xf86LoadModules () #10 0x0806db2a in InitOutput () #11 0x080d36c1 in main () does LoadModule() ring a bell? why don't you realize that there's a world beyond RedHat and that you *do* break those people's system? heck, you did break RedHat users' systems as well, you say so yourself: [2] or [3]. every time you suggest that a user upgrade X means that you have broken his existing binary - a clear no-no by your own rules. > X does break if you force exec-shield=2, and it did break even with > exec-shield=1 in earlier iterations of exec-shield, but that bug has been > fixed. excerpt from [1]: --- linux/kernel/sysctl.c.orig +++ linux/kernel/sysctl.c @@ -52,6 +52,9 @@ extern int core_uses_pid; extern char core_pattern[]; extern int cad_pid; +int exec_shield = 2; +int exec_shield_randomize = 1; that to me means that *everyone* will have his *existing* binary broken, by your own admission. it also means that you have violated the very rule of Linus you had referred to before. > the XFree86 patching you refer to above we did was to enable non-exec > stack. But this was an iterative thing to enhance security, not something > we had to do because X broke due to exec-shield itself. XFree86 never needed an executable stack as far as i know, what was there to 'enhance' then? it is clear that XFree86 did break because of Exec-Shield and you had to modify both to get it to work and be able to claim that it works out of the box. incidentally, if i were to make use of PT_GNU_STACK in PaX, i could claim the same - now what was your point of fighting this silly issue? by the way, on another look at your patch i noticed the following: 1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables() but don't make use of it, probably it's not needed at all now. 2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state between mpnt->vm_page_prot and mpnt->vm_flags, the former should be derived from the latter, just like do_mmap_pgoff() does it. [1] http://people.redhat.com/mingo/exec-shield/exec-shield-2.4.22-G4 [2] http://marc.theaimsgroup.com/?l=linux-kernel&m=106482772021534&w=2 [3] http://marc.theaimsgroup.com/?l=linux-kernel&m=106502603232695&w=2 From nobody Sun Nov 9 12:20:41 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 6 Nov 2003 14:47:30 +0100 (CET) Lines: 36 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA92DB2.20276.9A08A69@localhost> <3FAA5986.8511.E33BD52@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068126641 21931 80.91.224.253 (6 Nov 2003 13:50:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 13:50:41 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 14:50:39 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHkX0-0002P9-00 for ; Thu, 06 Nov 2003 14:50:39 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 0C0131F768; Thu, 6 Nov 2003 07:47:55 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id 0B61E1F56A for ; Thu, 6 Nov 2003 07:47:39 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id 1E67649A5A; Thu, 6 Nov 2003 14:47:38 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 85F9D1FC2; Thu, 6 Nov 2003 14:47:33 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FAA5986.8511.E33BD52@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155169 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 07:47:55 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44553 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44553 On Thu, 6 Nov 2003 pageexec@freemail.hu wrote: > > actually, unmodified XFree86 works just fine. It will have an executable > > stack but it will work out of box - so no app was broken. > > false! my unmodified X server (gentoo) dies with the following core > when trying to run it under [1]: you need to update your gcc, glibc and binutils chain and change exec-shield=1 (all the code is available under the GPL) to get a fully compatible exec-shield solution. the patches on my site default to exec-shield=2. exec-shield=2 means blanket non-exec stacks for _every_ binary. You are trying to make a big fuss about this for no good reason. My patches default to 2 to get wider testing without having to recompile all of userspace. (but recompiling all of userspace shouldnt be an issue on your gentoo box.) > > X does break if you force exec-shield=2, and it did break even with > > exec-shield=1 in earlier iterations of exec-shield, but that bug has been > > fixed. > > excerpt from [1]: > +int exec_shield = 2; Look at the Fedora Core 1 distribution released yesterday to see the complete solution - there exec-shield defaults to 1. You need PT_GNU_STACK markings for all apps to work under exec-shield. It cannot be solved via a single kernel patch. If exec-shield is to be added to Debian then this should be done too. Ingo From nobody Sun Nov 9 12:20:41 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 06 Nov 2003 15:12:04 +0100 Lines: 10 Approved: news@gmane.org Message-ID: <3FAA64C4.14184.E5FA8A3@localhost> References: <3FAA5986.8511.E33BD52@localhost> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1068129114 27819 80.91.224.253 (6 Nov 2003 14:31:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 14:31:54 +0000 (UTC) Cc: debian-devel@lists.debian.org, spender@grsecurity.net, Peter Busser Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 15:31:52 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHlAt-0005Bn-00 for ; Thu, 06 Nov 2003 15:31:52 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E1EB31F83B; Thu, 6 Nov 2003 08:30:23 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0603.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id 231DD1F731 for ; Thu, 6 Nov 2003 08:12:27 -0600 (CST) Original-Received: from angel (APastourelles-107-1-11-158.w217-128.abo.wanadoo.fr [217.128.154.158]) by mwinf0603.wanadoo.fr (SMTP Server) with ESMTP id EB98424000F7; Thu, 6 Nov 2003 15:12:25 +0100 (CET) Original-To: Ingo Molnar Priority: normal In-reply-to: X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: <0HFdS.A.7oF._rlq_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155172 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 08:30:23 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44556 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44556 > You are trying to make a big fuss about this for no good reason. Ingo, please. it was *you* who objected to PaX's default enforcement policy because it broke Linus's rule. yet you did the same with your own default *and* contested the fact that you hadn't broken anything. i don't have a problem with your choice for default policies, i have a problem when you have a double standard ('kettos merce' in your mother tongue). From nobody Sun Nov 9 12:20:42 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 6 Nov 2003 15:36:42 +0100 (CET) Lines: 38 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA92DB2.20276.9A08A69@localhost> <3FAA5986.8511.E33BD52@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068130111 30265 80.91.224.253 (6 Nov 2003 14:48:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 14:48:31 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 15:48:28 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHlQy-0006Ld-00 for ; Thu, 06 Nov 2003 15:48:28 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id B108D1F9A9; Thu, 6 Nov 2003 08:45:52 -0600 (CST) Old-Return-Path: Original-Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by murphy.debian.org (Postfix) with ESMTP id 43E731F81B for ; Thu, 6 Nov 2003 08:45:35 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id ABCC345F24; Thu, 6 Nov 2003 15:36:45 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 44C0C1FC2; Thu, 6 Nov 2003 15:36:45 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FAA5986.8511.E33BD52@localhost> Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155173 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 08:45:52 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44557 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44557 On Thu, 6 Nov 2003 pageexec@freemail.hu wrote: > [...] incidentally, if i were to make use of PT_GNU_STACK in PaX, i > could claim the same - now what was your point of fighting this silly > issue? yes, this was precisely my point to discuss this issue. Executability of the stack is not some divine privilege given to the sacred few, distributed via matters of public policy determined by the ruler of the system, it's simply a property of the code written. The system ought to detect it automatically and not stand in the way. We implemented the code for this - and the compiler, toolchain and glibc supports it all across. If PaX makes use of PT_GNU_STACK [just take the binfmt_elf.c bits] then this portion of PaX will conform to the Linus rule too. This is not some magic property only attached to exec-shield. this is i believe the main goal, in the quest to bring security to the average user. The only way to do that is to concentrate all technology on making security as automatic and hassle-free as possible. i hope we've finally settled this issue, right? You might still think of me in unfavorable terms but i've got to live with that :-) > by the way, on another look at your patch i noticed the following: > > 1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables() > but don't make use of it, probably it's not needed at all now. > > 2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state > between mpnt->vm_page_prot and mpnt->vm_flags, the former should > be derived from the latter, just like do_mmap_pgoff() does it. thanks, i'll fix these! Ingo From nobody Sun Nov 9 12:20:42 2003 Path: main.gmane.org!not-for-mail From: pageexec@freemail.hu Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 06 Nov 2003 17:08:08 +0100 Lines: 141 Approved: news@gmane.org Message-ID: <3FAA7FF8.8538.EC9EB77@localhost> References: <3FA92DB2.20276.9A08A69@localhost> Reply-To: pageexec@freemail.hu NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1068135978 16853 80.91.224.253 (6 Nov 2003 16:26:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 16:26:18 +0000 (UTC) Cc: debian-devel@lists.debian.org, Peter Busser , spender@grsecurity.net Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 17:26:14 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHmxa-0005i0-00 for ; Thu, 06 Nov 2003 17:26:14 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 25CF11FA34; Thu, 6 Nov 2003 10:25:15 -0600 (CST) Old-Return-Path: Original-Received: from mwinf0601.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by murphy.debian.org (Postfix) with ESMTP id D49681F9FC for ; Thu, 6 Nov 2003 10:08:31 -0600 (CST) Original-Received: from angel (APastourelles-107-1-11-158.w217-128.abo.wanadoo.fr [217.128.154.158]) by mwinf0601.wanadoo.fr (SMTP Server) with ESMTP id 5AB1A3400140; Thu, 6 Nov 2003 17:08:30 +0100 (CET) Original-To: Ingo Molnar Priority: normal In-reply-to: X-Mailer: Pegasus Mail for Windows (v4.12a) Content-description: Mail message body Resent-Message-ID: Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155177 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 10:25:15 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44561 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44561 > > [...] randomization serves NO purpose in the grand scheme, it does not > > provide guaranteed protection against the PaX attack model (arbitrary > > read/write access to the address space). [...] > > there's another, practical aspect of address-space randomization which i > find to be the most important: to make worms uneconomic in network > bandwidth terms. having non-executable pages achieves the same *and* guarantees failure (vs. the probabilistic failure/success rate of randomization), that's why i said that randomization played no role 'in the grand scheme'. the fact it's still useful these days is the consequence of our inability to effectively protect against the attack methods 2 and 3 i had referred to earlier (luckily for the defense side, existing worms have used attack method 1 but i would not rely on that in the future). > i took the 'they are broken for good' as equivalent to 'concepts flawed by > design', and 'important privilege that should be carefully managed' as a > signal of your belief that the ability to generate code should be > restricted. I do not agree with this direction. 'they are broken for good' means just that, they are no longer able to run under PaX without tagging (at least not when PaX is configured in its optimal form, that is, with non-exec pages and MPROTECT on). you're correct with what i meant by 'managed' although i think you may not like it because of the choice of my wording, not because what i meant. if i say 'we need an API to allow userland to generate code at runtime', will you still disagree with that (meaning 'disagree on principles', not the suggested implementation)? > The moment you start to 'manage' stuff that you believe is > 'broken for good' it ends up being less accessible to people. 'root for everyone!' - isn't that concept 'broken for good' (in the sense you originally interpreted it, i.e., 'flawed by design')? see, we do change systems to be able to 'manage stuff' even if that means that we'll make that stuff 'less accessible to people' (how many times do system admins have to do things on behalf of their users because said users are now not allowed to do it themselves?). so what am i getting at here? the fact that secure (heck, even just usable) systems should follow the principle of 'least privilege'. in the multi-user system case, it says (among others) that if a user does not need to have the privilege of root (read: complete system control), then he should not have it, hence we have the concept of UIDs (and capabilites, as the case may be). in the PaX memory protection case it means that if an application does not need the privilege to generate code at runtime, then it should not have it. interestingly enough, this is exactly what i say in [3] - did you read/understand it? if you did, then you should have realized that you can argue only about whether you want to follow a least privilege policy in this case, you cannot argue about how to do it because there's just one way (the memory protection concept of PaX). > I would like to see all these security technologies to show up on Joe > Average's desktop, so government-style manual need-to-know access control > just doesnt cut it. It might work if packaged very very carefully with > lots of care towards making it simple, but i see zero efforts in that > direction. i would not call [1] or [2] 'zero efforts'. > > you said a lot about what you don't agree with in PaX, what exactly > > prevented you from changing it *yourself*? what prevents *you* from > > disabling MPROTECT by default for example? > > we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did > seem to be a reasonable person with tons of experience and this matters > alot when considering patches) and the killer at that time was the 1.5 GB > VM limitation on x86. Exec-shield, as coarse as it might be, does here and > today offer quite acceptable non-executability coverage of all actual apps > we checked, and this is what counts. (Nobody puts bogus mprotect(argv) > calls into these apps to disable exec-shield so exec-shield just works.) [...] > the mprotect argument came not from my ability to enable or disable it in > PaX, but from the claim/impression that the (mprotect) tests in paxtest > constitude actual 'Vulnerabilities'. So i simply said i dont intend to > restrict mprotect semantics in exec-shield and explained my reasons for > doing so. i'm sorry that you still haven't realized what PaX/paxtest are about. PaX works against *exploit*methods* and paxtest simulates the core steps of those methods to determine to what extent they work on a given system. what you call 'bogus' again shows your misunderstanding of how one writes exploits. let's do some thinking: why did you write Exec-Shield (non-exec pages, randomization)? to make exploit methods non-working. now the question is, have you achieved that goal or not? or a bit harder question: what did you achieve exactly? my answers are below: Exec-Shield prevents existing exploits that rely on injecting/executing their own payload from working (well, more or less, there can be cases like with multithreaded apps on a non-RedHat system where such payload shows up in a writable/executable part of the address space since such does exist under Exec-Shield, unlike PaX). i'd like to stress *existing* in the above because it leads to the next question: what can you say about *future* exploits? what can you say about the *possibility* of creating exploits that circumvent Exec-Shield? you cannot make any generic claim either way because of the lack of design in Exec-Shield. you can make claims about what is needed to circumvent it, like the attacker needs to do a return-to-libc style exploit to call mmap/mprotect and elevate the executable region limit so that he can simply execute his payload just like he did so in the past. however you cannot claim whether this is possible for a given bug or not, at least not until you or someone examines the precise circumstances and determines whether it's possible or not. who's gonna do this every time a new bug becomes public? why do we even have to ask this question and waste precious human resources to answer it? see, that's the difference between PaX and everything else i know of: PaX gives you guarantees and you can sleep a bit better because you can rest assured as to what an attacker can do with a bug (in the future that 'what' will be 'nothing beyond denial of service'). you don't understand/care about such assurance - that's your personal choice but there are people who think otherwise and don't appreciate your calling PaX methods 'bogus'. > > [...] see, there're just cases when userland is plain wrong and must be > > fixed. [...] > > there's nothing wrong about an executable stack though. It's been part of > Linux ever since. the brk() managed heap has also been executable. yet you break apps that assume so (the ominous XFree86 server would also use the brk() managed heap if you were to tell malloc() to not use mmap() at all or for 'big' areas only, well beyond the default 128k. actually, for 'small' modules XFree86 does use the brk() heap). speaking of breakage, you didn't not react on Exec-Shield breaking POSIX/SUSv3 - any comments? [1] http://adamantix.org [2] http://www.gentoo.org/proj/en/hardened [3] http://pageexec.virtualave.net/docs/noexec.txt From nobody Sun Nov 9 12:20:44 2003 Path: main.gmane.org!not-for-mail From: Ingo Molnar Newsgroups: gmane.linux.debian.devel.general Subject: Re: Exec-Shield vs. PaX Date: Thu, 6 Nov 2003 17:19:52 +0100 (CET) Lines: 20 Sender: mingo@earth.elte.hu Approved: news@gmane.org Message-ID: References: <3FA92DB2.20276.9A08A69@localhost> <3FAA7FF8.8538.EC9EB77@localhost> Reply-To: Ingo Molnar NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1068135680 12543 80.91.224.253 (6 Nov 2003 16:21:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2003 16:21:20 +0000 (UTC) Cc: debian-devel@lists.debian.org Original-X-From: bounce-debian-devel=debian-devel=m.gmane.org@lists.debian.org Thu Nov 06 17:21:18 2003 Return-path: Original-Received: from murphy.debian.org ([146.82.138.6]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AHmso-0005Cn-00 for ; Thu, 06 Nov 2003 17:21:18 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 086AD1FA2D; Thu, 6 Nov 2003 10:20:09 -0600 (CST) Old-Return-Path: Original-Received: from mx2.elte.hu (mx2.elte.hu [157.181.151.9]) by murphy.debian.org (Postfix) with ESMTP id 5AD701FA1C for ; Thu, 6 Nov 2003 10:19:59 -0600 (CST) Original-Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id 7DA1548E23; Thu, 6 Nov 2003 17:19:58 +0100 (CET) Original-Received: by chiara.elte.hu (Postfix, from userid 17806) id 04B031FC2; Thu, 6 Nov 2003 17:19:57 +0100 (CET) Original-To: pageexec@freemail.hu In-Reply-To: <3FAA7FF8.8538.EC9EB77@localhost> Resent-Message-ID: <6STFeC.A.0WG.4Snq_@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: archive/latest/155176 X-Loop: debian-devel@lists.debian.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Archive: Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Resent-Date: Thu, 6 Nov 2003 10:20:09 -0600 (CST) Xref: main.gmane.org gmane.linux.debian.devel.general:44560 X-Report-Spam: http://spam.gmane.org/gmane.linux.debian.devel.general:44560 On Thu, 6 Nov 2003 pageexec@freemail.hu wrote: > > there's nothing wrong about an executable stack though. It's been part of > > Linux ever since. > > the brk() managed heap has also been executable. yet you break apps that > assume so (the ominous XFree86 server would also use the brk() managed > heap if you were to tell malloc() to not use mmap() at all or for 'big' > areas only, well beyond the default 128k. actually, for 'small' modules > XFree86 does use the brk() heap). yes. This is one reason why exec-shield isnt ready for the mainline kernel (and might never be). Fortunately, executable malloc() assumptions seem to be much less widespread than the reliance on an executable stack. But you are right of course, exec-shield breaks the 'Linus rule' too. Ingo